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[57] ABSTRACT 

The present invention provides a method and apparatus for 
the distribution of objects and the sending of messages 
between objects that are located in different processes. 
Initially, a “proxy” object is created in the same process as 
a sender object. This proxy acts as a local receiver for all 
objects in the local program. When the proxy receives a 
message, the message is encoded and transmitted between 
programs as a stream of bytes. In the remote process, the 
message is decoded and executed as if the sender was 
remote. The result follows the same path, encoded, trans- 
mitted, and then decoded back in the local process. The 
result is then provided to the sending object. 

24 Claims, 6 Drawing Sheets 
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METHOD FOR PROVIDING AUTOMATIC 

AND DYNAMIC TRANSLATION OF OBJECT 
ORIENTED PROGRAMMING 
LANGUAGE-BASED MESSAGE PASSING 
INTO OPERATION SYSTEM MESSAGE 
PASSING USING PROXY OBJECTS 

BACKGROUND OF THE PRESENT 
INVENTION 

This is a continuation of application Ser. No. 07/731,636 
filed Jul. 17, 1991, now abandoned. 

FIELD OF THE INVENTION 

This invention relates to the field of object-oriented 
programming and distributed computing. 

BACKGROUND ART 

Object-oriented programming is a method of creating 
computer programs by combining certain fundamental 
building blocks, and creating relationships among and 
between the building blocks. The building blocks object- 
oriented programming systems are called “objects.” An 
object is a programming unit that groups together a data 
structure (instance variables) and the operations (methods) 
that can use or affect that data. Thus, an object consists of 
data and one or more operations or procedures that can be 
performed on that data. The joining of data and operations 
into a unitary building block is “encapsulation.” In object- 
oriented programming, operations that can be performed on 
the data are referred to as “methods.” 

An object can be instructed to perform one of its methods 
when it receives a “message.” A message is a command or 
instruction to the object to execute a certain method. It 
consists of a method selection (name) and arguments that are 
sent to an object. A message tells the receiving object what 
to do. 

One advantage of object-oriented programming is the way 
in which methods are invoked. When a message is sent to an 
object, it is not necessary for the message to instruct the 
object how to perform a certain method. It is only necessary 
to request that the object execute the method. This greatly 
simplifies program development. 

Object-oriented programming languages are generally 
based on one of two schemes for representing general 
concepts and sharing knowledge. One scheme is known as 
the “class” scheme. The other scheme is known as the 
“prototype” scheme. Both the set-based and prototype-based 
object-oriented programming schemes are generally 
described in Lieberman, “Using Prototypical Objects to 
Implement Shared Behavior in Object-Oriented Systems,” 
OOPSLA 86 Proceedings, September 1986, pp. 214—223. 

Class Scheme 

An object that describes behavior is called a “class.” 
Objects that acquire a behavior and that have states are 
called “instances.” Thus, in the objective C language, which 
is the computer language in which the preferred embodiment 
of the present invention is implemented, a class is a par- 
ticular type of object. In objective C, any object that is not 
a class object is said to be an instance of its class. The classes 
form a “hierarchy.” Each subclass in the hierarchy may add 
to or modify the behavior of the object in question and may 
also add additional states. Inheritance is a fundamental 
property of the class scheme and allows objects to acquire 
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behavior from other objects. 

The inheritance hierarchy is the hierarchy of classes 
defined by the arrangement of superclasses and subclasses. 
Except for the root classes, every class has a superclass, and 
5 any class may have an unlimited number of subclasses. Each 
class inherits from those classes above it in the hierarchy. 
Thus, a superclass has the ability to pass its characteristics 
(methods and instance variables) onto its subclasses. 

FIG. 1 is a block diagram that illustrates inheritance. 
10 Class 1 (generally indicated by block 101) defines a class of 
objects that have three methods in common, namely. A, B 
and C. An object belonging to a class is referred to as an 
“instance” of that class. An example of an instance of class 
1 is block 102. An instance such as instance 102 contains all 
15 the methods of its parent class. Block 102 contains methods 
A, B and C. 

As discussed, each class may also have subclasses, which 
also share all the methods of the class. Subclass 1.1 (indi- 
20 cated by block 103) inherits methods A, B and C and defines 
an additional method, E. Each subclass can have its own 
instances, such as, for example, instance 104. Each instance 
of a subclass includes all the methods of the subclass. For 
example, instance 104 includes methods A, B, C and E of 
25 subclass 1.1. 

Not all object oriented programming languages permit 
new methods to be added per instance. For, example, in 
Objective C, an instance can not have methods that are not 
contained in its parent class. 

30 A disadvantage of an inheritance-based, object-oriented 
programming language is object size. Because each subclass 
must, by definition, include all methods of its parent class 
and super classes, instances are larger at the bottom of the 
inheritance hierarchy. 

35 Object-oriented programming languages that utilize the 
class/instance/inheritance structure described above imple- 
ment a set-theoretic approach to sharing knowledge. This 
approach is used in object-oriented programming languages, 
such as Simula, SmallTalk, Flavors and Loops. 

40 

Prototype Scheme 

The prototype scheme is an alternate approach to sharing 
knowledge in an object-oriented system. In prototype 
45 scheme systems that use the individual instances, rather than 
a class, (“prototypes”) are created first, instead of a class. 
The prototypes are then generalized by defining aspects of 
their concepts that are permitted to vary. The mechanism for 
implementing this process is known as “delegation.” 
50 Examples of prototype languages include the actor language 
and lisp-based object-oriented systems, such as director, t, 
and orbit. 

Delegation removes the distinction between classes and 
instances. To create another object that shares knowledge 
55 with a prototype, an “extension” object is created that has a 
list containing its prototypes that may be shared with other 
objects and containing personal behavior limited to the 
object itself. When an extension object receives a message, 
it attempts to respond to the message using the behavior 
50 stored in its personal aspect. If the object’s personal char- 
acteristics are not suitable to answer the message, the object 
forwards the message on to other prototypes to see if one can 
respond to the message. This method of forwarding is called 
“delegating the message.” 

65 An example of delegation is illustrated in FIG. 2. Object 
A provides a message 201 to object B. The message includes 
a method and arguments to the method. Object B does not 
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have the method required by the message. Therefore, object 
B cannot respond to the message. Instead, object B sends the 
method and message to its delegate. The delegate of object 
B is object C. Object C has the method requested in the 
message. The method can then be executed and a response 
provided to object A. 

Distributed Programming 

A disadvantage of current object-oriented programming 
systems is that all objects are required to exist in a single 
program or process. This prohibits utilizing an object- 
oriented programming system when writing distributed 
applications. In addition, these prior art limitations prevent 
the creation of applications that are distributed physically 
over networks of machines. 

The difficulty of creating distributed object-oriented pro- 
grams is illustrated in FIGS. 8A and 8B. In FIG. 8A, all 
objects are resident in the same program, namely program 
LOCAL 801. A sender object 802 sends a message 804 to a 
receiver 803. The message may include a method and an 
argument. The receiver 803 executes the method of the 
message 804 and returns a result 805. The result 805 is 
provided back to the sender 802. In the example of FIG. 8A, 
the object-oriented program resides entirely on one side of 
a boundary 806. 

FIG. 8B illustrates a prior art object-oriented program- 
ming system attempting to communicate across a boundary 
between processes. A local process 801 includes a sender 
object 802 that generates a message 804 destined for 
receiver object 808. However, object 808 is on the opposite 
side of boundary 806. That is a separate process identified as 
REMOTE 807. An object, such as receiver 808 which 
resides in a different process than a sender object, is known 
a “remote object.” The language and run time support of the 
local process 801 does not provide a mechanism to send a 
message 804 directly to the remote object 808. At the 
transition point 809 of boundary 806, the message is 
stopped. 

One prior art approach for writing distributed applications 
consists of explicitly defining the boundaries between dif- 
ferent programs by specifying protocols, generating client/ 
server stubs, and communicating between processes or pro- 
grams by using function calls that automatically transport 
arguments and return values between the client layer and the 
server layer. At such boundaries, the object-oriented devel- 
oper can no longer treat items as objects as soon as the 
boundary of the process is crossed. This defeats the purpose 
and advantage of using object-oriented programming in the 
first place. 

Another prior art method for providing distributed object 
oriented programming is described in “Design of a Distrib- 
uted Object Manager for the SmallTalk-80System,” D. 
Decouchant, OOPSLA 86 Proceedings, September, 1986, 
pp. 444-452. The Decouchant reference describes the design 
of a distributed object manager that allows several Small- 
Talk-80 systems to share objects over a local area network. 
When a local object desires to communicate with a remote 
object, the local object communicates with a “proxy” that 
locally represents the remote object. A proxy is part of the 
private data of the object manager. The proxy has two fields 
that describe a remote object, namely, the resident site of the 
remote object and a virtual pointer to the object in the 
resident site. If the referenced object migrates, the contents 
of the referencing object are not modified. The proxy is 
updated accordingly by the object manager. In this imple- 
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mentation, a proxy is functionally equivalent to a Unix link, 
except that a proxy is not visible to the programmer. It is a 
private data structure which is handled by the object man- 
ager like other Small-Talk objects. 

5 In the Decouchant reference, three processes cooperate to 
perform the object manager functions. These are the network 
manager, the main memory manager and the secondary 
manager. SmallTalk interpreter processes which access the 
objects to perform SmallTalk actions may also be present on 
10 the site. The network manager is the master process of a 
SmallTalk site. It ensures consistency of the shared objects 
with the other network sites and controls the local processes. 
The main memory manager is in charge of the object 
management in main memory. It resolves object faults by 
15 allocating free space for the missing object and sending an 
object load request to the secondary storage manager. The 
secondary memory manager takes care of the object man- 
agement in secondary storage. This storage is represented by 
two files, one of which contains the SmallTalk object table 
20 and the other one contains the object space. 

Another prior art method to provide distributed object- 
oriented programming is described in “The Design and 
Implementation of Distributed SmallTalk,” John K. Bennett, 
OOPSLA, Oct. 4-8, 1987, pp. 318-330. SmallTalk itself is 
25 a language environment that provides a single user with 
access to a single object address space. Only rudimentary 
support exists within SmallTalk for cooperation among 
users, and no support exists within SmallTalk for object 
sharing between users or between different machines or 
0 between processes on the same or different machines. The 
Bennett references describes “distributed SmallTalk” (DS) 
as a method of providing improved communication and 
interaction among geographically remote SmallTalk users, 
direct access to remote objects, the ability to construct 
35 distributed applications in a SmallTalk environment, and a 
degree of object sharing among users. 

The system described in the Bennett reference does not 
allow remote classes. Instead, the system requires that 
40 classes and instances be co-resident on all processes and 
machines. This impacts object mobility adversely. Instances 
can only move to hosts with compatible classes and insuring 
class compatibility is difficult. In addition, the system of 
Bennett does not operate in an object-oriented programming 
45 system that utilizes class inheritance and reactiveness. 
(Reactiveness describes the ability of a system to present 
objects for inspection or modification). 

The system of Bennett uses ProxyObjects and a Remo- 
teObjectTable to implement distributed message passing. A 
50 ProxyObject represents a remote object to all objects in a 
local address space. There is one ProxyObject per host per 
remote object referenced by that host. ProxyObjects cause a 
remote object’s message interface to appear to local objects 
as if the remote object were locally resident. ProxyObjects 
55 redefine the doesNotUnderstand: message of object. This is 
the primary message defined for ProxyObjects. In other 
words, messages sent to ProxyObjects are intended to fail. 
The system responds to this failure by sending the message 
doesNotUnderstand: to the receiver with the message that 
60 was not understood as an argument. The ProxyObject’ s 
response to the doesNotUnderstand: message is to forward 
the original message to the RemoteObjectTable on the 
appropriate machine or process. The location of the remote 
object is part of the internal state of the ProxyObject. 

65 The RemoteObjectTable is responsible for receiving and 
replying to messages forwarded by ProxyObjects. There is 
one RemoteObjectTable per host. It is the sole instance of 
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class RemoteObjectTable. The RemoteObjectTable can be 
thought of as a set of extensions to the object tables (if 
present) of all remote machines. The RemoteObjectTable 
keeps track of all local objects that are remotely referenced. 
When the RemoteObjectTable receives a message from 
some ProxyObject, it schedules a process that will contain 
the execution context of the actual message receiver by 
sending the message perform to the receiver with the for- 
warded selector and arguments (if any) as arguments to the 
perform message. The value returned by the perform mes- 
sage is returned to the remote sender in a reply message 
constructed by the RemoteObjectTable. 

Before an object can be sent between processes, the 
classes must be checked for compatibility. The three cases to 
consider are: 

1. The required class is already present and is compatible; 

2. The required class is present, but it is determined to be 
incompatible; and 

3. The required class is not present. 

In case 1, the system proceeds normally. In the second 20 

case, the attempted move fails and the user is notified of the 
error. In case 3, the user is asked whether the desired object’s 
class should be moved. If the response is affirmative, the 
object’s super class is checked for compatibility. This pro- 
cedure continues up the class hierarchy until class object is 25 
reached. However, class object may not be moved. 

Another method for providing distributed object-oriented 
programming is described in “Transparent Forwarding: First 
Steps” Paul L. McCullough, OOPSLA 1987 Proceedings, 
Oct. 4-8, 1987, pp. 331-341. As in the Bennett system, the 30 
McCullough system utilizes ProxyObjects and the doesNo- 
tUnderstand: message for identifying and transmitting mes- 
sages. In the McCullough system, the implementation of 
doesNotUnderstand: creates an ethemet packet containing 
the original message and forwards it to the machine con- 35 
taining the remote object. The proxy contains information in 
its instance variables about where the remote object resides. 

FIG. 6 illustrates an overview of the operation of the 
McCullough system. A message 601 destined for a remote 
object is provided to a ProxyObject 602. The ProxyObject 40 
instance forms a representation of the message, including 
both the selector and the arguments, suitable for transmis- 
sion to a remote machine. This message 603 is forwarded 
across the process boundary 606 to a remote object 604. The 
remote object 604 receives the representation of the mes- 45 
sage, extracts the message selector and arguments and 
executes the message send as though it originated on the 
same machine as the remote object. This result object 605 is 
transmitted across the process boundary 606 to the Proxy- 
Object 602. The ProxyObject 602 uses the return represen- 50 
tation to reconstruct the result object and returns it to the 
sender of the original message 601. 

The McCullough system implements four possible mes- 
sage parameter passing schemes, namely, pass by value, pass 
by reference, pass by proxy and pass by migration. In pass 55 
by value, a representation of the object is shipped to the 
remote machine, which in turn reconstructs the object. Pass 
by reference cannot be used in a SmallTalk environment 
because the compiler prevents assignment to formal param- 
eter variables. In pass by proxy, a proxy for the object and 60 
any messages which are sent to the proxy are automatically 
forwarded to the remote object. In pass by migration, we 
move an object from one machine to another, leaving a 
proxy object in its prior home. 

A centralized control scheme, referred to as PolicyMaker, 65 
is used to deliver messages to remote objects. Individual 
proxies need not record the current network location of a 
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shared object, that is the responsibility of the PolicyMaker. 
PolicyMaker responsibilities include the decision of whether 
to pass objects by value, proxy or by migration, and whether 
to forward a message to a remote object or whether to 
5 migrate the object to the local machine for execution. In 
addition, PolicyMaker keeps track of open connections 
between machines. For each connection to a remote 
machine, the PolicyMaker creates an instance of class Trans- 
porterRoom. The TransporterRoom takes care of communi- 
io cations protocols between machines, as well as the linear- 
ization of messages and objects. 

FIG. 7 illustrates the flow control of sending a message 
from a machine to a remote object using the scheme of the 
McCullough system. A message 701, destined for a remote 
15 object, is provided to a ProxyObject 702. The sender of the 
message 701 believes it is sending to a local object, but in 
reality it is sending to a remote object. The ProxyObject 702 
sends a message 703 to the local PolicyMaker 704. The 
PolicyMaker 704 determines whether the arguments of the 
message should be sent by copying or by proxy to the remote 
object. The PolicyMaker establishes a connection to the 
remote machine via transporter room 706. The PolicyMaker 
704 provides the message 705 to the TransporterRoom 706. 
The TransporterRoom 706 linearizes and transmits the mes- 
sage as message 707 to the remote machine across process 
boundary 708. 

The TransporterRoom 709 of the remote machine receives 
the message 707. The TransporterRoom 709 sends the 
reconstructed message 710 to the remote object 711. The 
remote object 711 returns a message 714 to the Transport- 
erRoom 709. The PolicyMaker 712 considers the resulting 
object and determines whether to return it by value or by 
proxy and communicates to the TransporterRoom 709 on 
path 713. The TransporterRoom 709 sends the message 707 
to the TransporterRoom 706 across process boundary 708. 
The TransporterRoom 706 reconstructs the result object and 
provides it as message 715 to proxy object 702, which can 
then return it to the sending context. 

The use of migration limits the performance and ease of 
use of these prior art schemes. Migration of objects from 
their home process adds to the complexity of the system. 
Another disadvantage of these prior art schemes is that each 
process and thread must be forked to anticipate each 
expected iteration. There is no provision for dynamic recur- 
sive communication between processes. In addition, these 
prior art schemes rely on a pure, large object oriented 
language/environment, such as SmallTalk. This requires 
substantial run time support to implement communication 
between processes. In addition, the prior art schemes do not 
implement suitable object collection methods. 

SUMMARY OF THE INVENTION 

The present invention permits the distribution of objects 
and sending of messages between objects that are located in 
different processes. Initially, a “proxy” object is created in 
the same process as a sender object. This proxy acts as a 
local receiver for all objects in the local program. When the 
proxy receives a message, the message is encoded and 
transmitted between programs as a stream of bytes. In the 
remote process, the message is decoded and executed as if 
the sender was remote. The result follows the same path, 
encoded, transmitted, and then decoded back in the local 
process. The result is then provided to the sending object. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram illustrating the concept of 
inheritance in object-oriented programming. 
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FTG. 2 is a block diagram illustrating delegation in 
object-oriented programming. 

FIGS. 3A-3C illustrate the distributed processing object 
oriented programming system of the present invention. 

FIG. 4 is a block diagram illustrating a general purpose 5 
computer system for implementing the present invention. 

FIG. 5 is a flow diagram of the forwarding method of the 
present invention. 

FIG. 6 is a block diagram illustrating the prior art dis- 10 
tributed processing object-oriented programming system. 

FIG. 7 is a block diagram illustrating another prior art 
distributed processing object-oriented programming system. 

FIGS. 8 A and 8B illustrate non-distributed programming 
systems. 15 

DETAILED DESCRIPTION OF THE 
INVENTION 

A method and apparatus for distributed execution of 
methods is described. In the following description, numer- 20 
ous specific details, such as object-oriented programming 
language, operating system, etc., are set forth in detail in 
order to provide a more thorough understanding of the 
present invention. It will be apparent, however, to one 
skilled in the art, that the present invention may be practiced 25 
without these specific details. In other instances, well known 
features have not been described in detail so as not to 
obscure the present invention. 

The present invention may be implemented on any con- ;j() 
ventional or general purpose computer system. An example 
of one embodiment of a computer system for implementing 
this invention is illustrated in FIG. 4. A keyboard 410 and 
mouse 411 are coupled to a bi-directional system 419. The 
keyboard and mouse are for introducing user input to the 3J 
computer system and communicating that user input to CPU 
413. The computer system of FIG. 4 also includes a video 
memory 414, main memory 415 and mass storage 412, all 
coupled to bi-directional system bus 419 along with key- 
board 410, mouse 411 and CPU 413. The mass storage 412 4Q 
may include both fixed and removable media, such as 
magnetic, optical or magnetic optical storage systems or any 
other available mass storage technology. The mass storage 
may be shared on a network, or it may be dedicated mass 
storage. Bus 419 may contain, for example, 32 address lines 4 _ 
for addressing video memory 414 or main memory 415. The 
system bus 419 also includes, for example, a 32-bit data bus 
for transferring data between and among the components, 
such as CPU 413, main memory 415, video memory 414 and 
mass storage 412. Alternatively, multiplex data/address lines - Q 
may be used instead of separate data and address lines. 

In the preferred embodiment of this invention, the CPU 
413 is a 32-bit microprocessor manufactured by Motorola, 
such as the 68030 or 68040. However, any other suitable 
microprocessor or microcomputer may be utilized. The 55 
Motorola microprocessor and its instruction set, bus struc- 
ture and control lines are described in MC68030 User’s 
Manual, and MC68040 User’s Manual, published by 
Motorola Inc. of Phoenix, Ariz. 

Main memory 415 is comprised of dynamic random 60 
access memory (DRAM) and in the preferred embodiment 
of this invention, comprises 8 megabytes of memory. More 
or less memory may be used without departing from the 
scope of this invention. Video memory 414 is a dual-ported 
video random access memory, and this invention consists, 65 
for example, of 256 kbytes of memory. However, more or 
less video memory may be provided as well. 
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One port of the video memory 414 is coupled to video 
multiplexer and shifter 416, which in turn is coupled to 
video amplifier 417. The video amplifier 417 is used to drive 
the cathode ray tube (CRT) raster monitor 418. Video 
multiplexing shifter circuitry 416 and video amplifier 417 
are well known in the art and may be implemented by any 
suitable means. This circuitry converts pixel data stored in 
video memory 414 to a raster signal suitable for use by 
monitor 418. Monitor 418 is a type of monitor suitable for 
displaying graphic images, and in the preferred embodiment 
of this invention, has a resolution of approximately 1020x 
832. Other resolution monitors may be utilized in this 
invention. 

The computer system described above is for purposes of 
example only. The present invention may be implemented in 
any type of computer system or programming or processing 
environment. 

The preferred embodiment of the present invention imple- 
ments an object-oriented programming system using objec- 
tive C language. Objective C is an extension to ANSI C that 
supports the definition of classes of objects and provides 
syntactic and run-time support for sending messages to 
objects. This language model is partially derived from 
SmallTalk and has been described in “Object-Oriented Pro- 
gramming; An Evolutionary Approach,” Brad J. Cox, Addi- 
son- Wesley 1986 and in “SmallTalk-80; The Language and 
its Implementation,” Adele Goldberg, Dave Robson, Addi- 
son- Wesley 1983. 

One feature of objective C is “dynamic binding” of 
messages to the actual methods to be invoked, depending on 
the class of the receiver. A programmer writing code in 
objective C can create code that sends a message “doSome- 
thing” to an object. The actual method corresponding to the 
class of the target object does not need to be determined until 
the message must be sent. This allows objects of any classes 
that implementing the doSomething method to be substi- 
tuted for the target object at run time without having to 
modify the part of the program that sends the message. Also, 
in objective C, programs have run time access to method 
“signatures,” that encode a method’s argument and return 
types for each class. The method signature provides a way 
for two programs to agree on the format of messages. 
Moreover, there is a way to extract arguments from the stack 
using the signature. 

In its preferred embodiment, the present invention is 
implemented in a computer system using an object-oriented 
operating system. One such object-oriented operating sys- 
tem is known as the “Mach” operating system and is 
implemented on computers manufactured by NeXT, Inc., the 
Assignee of the present invention. 

The Mach operating system is an object-oriented operat- 
ing system that supports distributed programming. It is a 
multi-tasking operating system kernel, allowing multiple, 
independent “tasks,” which provide the basic environment 
of a program in the form of a demand-paged virtual “address 
space” and one or more “threads” of execution. Mach 
supports message-passing within and between tasks. This 
support is distinct from objective C messaging described 
earlier. 

Fundamental to Mach’s ability to deliver messages 
between different programs is an abstraction called a “port.” 
A Mach port is a buffered communication channel over 
which messages are sent. This channel, which is maintained 
by the operating system, may be local, may span two tasks 
on the same machine, or may span tasks on different 
machines. The physical location of the receiving end of a 
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port has no effect on the sender, which always sees a local 
reference to the port. 

The messages sent on a port are buffered, that is, a sender 
writes messages to a port with a “send” primitive, and a 
receiver accepts messages with a “receive” primitive. The 
messages themselves may be of any size, and consist of a 
header followed by zero or more data objects. For efficiency, 
large array arguments are passed out-of-line with copy-on- 
write semantics. Of particular interest is the ability to pass 
Mach ports themselves as data objects in a message. By this 
means, one task may pass a port to another, with the kernel 
maintaining address translation along the way. This allows 
tasks to learn about the existence of new external objects, or 
make new “acquaintances,” by receiving their ports in a 
message. Thus, ports may also be viewed as a reference for 
an object that is independent of any particular space, and 
may be freely passed between programs. 

For a task to communicate with a “receiver” object in 
another address space, it must first establish a connection 
with that program, and then create a local “proxy” for the 
object. When a message is sent to this proxy, the elements 
of the objective C message are encoded into a Mach mes- 
sage, which is then forwarded through a Mach port to the 
other program. On the receiving side, the message is 
received, decoded, and then forwarded it to the target 
objective C object. The return value of the objective C 
method is then encoded and sent back to the originator, 
where it is decoded and returned as the value. Each part of 
this model is now described. 

In order to communicate with an object in a different 
program or process, that program or process must be known. 
The present invention uses Mach ports to represent 
“domains” of objects, and a token to identify objects within 
that domain. This two-part address is easily communicated, 
since the port maintains its identity as it moves between 
domains. In Mach, acquiring ports is synonymous with 
acquiring privileges to communicate. The present invention 
requires that the local domain has send rights to a port that 
the remote domain has receive rights to, and also that the 
remote domain has send rights to a port that the local domain 
has receive rights to, before any communication can take 
place. Thus, mutual consent is required to communicate. 

In addition to learning of each other’s ports, each domain 
must also provide the other with the token corresponding to 
its “first proxy.” A first proxy is required to bootstrap the 
communication. There must be at least one known object in 
a remote domain before a message can be sent to it. Because 
a connection allows messages in either direction and initi- 
ated by either party, each side of a connection must have a 
first proxy. This first proxy may be viewed as the “recep- 
tionist” for the remote domain, as other objects are obtained 
(discovered) by asking this object. This object also is a 
candidate for implementing sender authentication. 

The present invention provides a means for implementing 
an extensible, distributed program in which one task is 
responsible for creating other tasks to communicate with. 
This is a master/slave relationship; the master can provide 
the slave with send rights to the master’s port as part of the 
creation process. When the slave starts executing, it sends a 
Mach message containing send rights to its port and a token 
for its first proxy back to the master. The master then replies 
with an indication of whether the connection is granted, and 
what token to use for the first proxy. This “bootstrap-meta- 
protocol” results in both tasks knowing about each other, 
allowing communication to ensue. 

Distributed Object Oriented Programming 

The present invention provides a method for different 
processes to communicate, using a traditional language- 
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based, message-passing paradigm. The present invention 
has a number of advantages over prior art methods of 
distributed object-oriented programming. These advantages 
include no pre-defined set of messages, transparent to the 
5 programmer, no code generation step and a method for 
bridging the gap between object-oriented languages and 
object-oriented operating systems. 

The present invention differs from the prior art 
approaches of Decouchant, Bennett and McCullough. The 
10 present invention uses an object-oriented superset of ANSI 
C with minimal run time support to implement transparent 
messaging between application programs as opposed to the 
prior art systems, that rely on a pure, large, dynamic 
object-oriented language/environment, such as SmallTalk. 
15 The present invention either implements a client/server 
setup or a master/slave setup that involves forking tasks to 
perform background operations and using the present inven- 
tion to communicate with these tasks. Because communi- 
cations are serialized by the operating system, remote mes- 
20 sages performed by a slave task appear to the program just 
like other asynchronous events, such as mouse clicks, allow- 
ing the design of a consistent user interface. Modularity, 
extensibility and safety are gained by spawning new tasks. 
The ability to implement recursive remote messaging is an 
25 important feature of the present invention, for example when 
user interaction is required to perform the desired task. 

The present invention can also be implemented in a 
client/server setup. In the client/server setup, both the client 
and the server begin independently. Communication is 
30 through an agreed upon method. The client and server can 
communicate with each other by looking for a manager for 
the communications channel (e.g. network). 

The present invention provides a new alternative for 
developing extensible programs. Instead of adding function- 
35 ality by adding code that defines new object classes and then 
loading that code into a main program, a new program is 
created and forked. If there are any errors in the new 
program, they reside outside the main program improving 
performance. In addition, processing is parallel and asyn- 
40 chronous, leading to improved performance. 

In one embodiment, the first time a message is sent to a 
proxy, the receiver is asked for the method signature in order 
to allow the proxy’s domain to encode the arguments. This 
45 can increase communication time. One alternative embodi- 
ment provides for prior agreement between processes so that 
two tasks know in advance the method signatures for their 
proxies. Alternatively, when prior agreement is not possible 
due to the dynamic nature of the required exchange, the 
50 atomicity of the signature request can be changed to com- 
municate all the public signatures for a given proxy, result- 
ing in a single “meta-protocol” transaction for the proxy. 

When an object is passed by reference, a new proxy is 
typically created. The present invention includes safeguards 
55 to guarantee that if a remote object is encoded twice, the 
same proxy (in the pointer equality sense) will be obtained 
in the local domain. This unicity of proxies is maintained by 
a table which maps tokens of remote objects to their local 
proxies and looks for previously created proxies when an 
60 object pass by reference is decoded. The present invention 
keeps all proxies until the communication with the remote 
domain ends. At that time, the table is used to de-allocate all 
proxies. 

The operation of the present invention is illustrated in 
65 FTGS. 3A-3C. Referring first to FIG. 3 A, a local process 
901 is separated from a remote process 902 by boundary 
906. The boundary 906 could be a separation between 
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programs on the same computer or it could represent the 
separation of two different machines on a network. The local 
process 901 includes a sender object 905 that sends a 
message to receiver object 909. The object 909 is located in 
the remote process 902. However, the sender object 905 can 
send its message 903 to the remote object as if it were a local 
object. 

The local process 901 includes a receiver proxy 904 that 
accepts the message 903. The receiver proxy 904 is an object 
that executes a forward:: method. The receiver proxy 904 
encodes the message and transmits it across the process 
boundary to the remote object. In the preferred embodiment 
of the present invention, the proxy 904 encodes the message, 
(which is a language based message such as, for example, an 
objective C message), as an operating system message, such 
as a Mach message 907, and transmits it to the receiver 
object 909 in the remote process 902. The receiver object 
909 decodes the Mach message into a language based 
message for execution or handling in the remote process 
902. 

The present invention supports nested, recursive, remote 
messages. That is, when a message is sent to a remote object, 
that remote object may send other messages back to the local 
process (which may again send other remote messages), as 
part of its calculations before providing a reply to the initial 
message. These messages may be nested arbitrarily deep. If 
only the sender itself is sent as an argument, (such as 
illustrated in FIG. 3 A), the receiver determines what further 
information is required from the sender and sends messages 
back to the local process to obtain that information before 
generating a reply. 

Referring to FIG. 3 B, the receiver object 909 requires 
additional information from the sender object so it generates 
a request message to the sender object 904. However, since 
the sender object 904 is not resident in the remote process 
902, a sender proxy 910 is created in the remote process 902. 
The sender proxy 910 encodes the request into a Mach 
message and transmits it across process boundary 906 to 
sender object 905. The Mach message is decoded into a 
language based message and generates a response. This 
response is sent back to the receiver object 909, (again via 
receiver proxy 904). 

Referring to FIG. 3 C, the receiver object 909 then 
performs an execute 911 on the original message to generate 
a result object 912. The result object 912 is encoded 913 and 
transmitted across process boundary 906 to result proxy 914 
in local process 901. 

In the present invention, proxies are not required to be 
created in advance. Once one proxy of a remote process 
exists, N proxies can be created for communication with that 
process. The present invention also permits the sending of 
objects themselves across process boundaries. 

The recursive nature of the present invention is useful 
when the remote object does not recognize a method sent to 
it by a local object. For example, the local object may send 
a message to a remote object requesting it to execute the 
method “foo”. If the remote object does not recognize the 
method, it can ask the sending object “what is foo?” All 
objects recognize the method “what is”. The sender object 
can then respond with instructions concerning the nature of 
the method being investigated. For example, the sender can 
reply that foo is a method that requires an integer. If no 
integer has been provided, the remote object can then 
request the integer. 

The creation of the first proxy is provided automatically 
in the present invention. The first time a process is accessed. 
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it must call a process referred to as the “proxy receptionist”. 
By definition, the first call to a new process is to be at 
sequence number 0. The first proxy by definition has a 
sequence number of 0. Subsequent proxies, as needed, are 
5 defined and the sequence numbers are provided to the other 
process. 

In the preferred embodiment of the present invention, 
communication between processes is implemented in a 
master/slave or client/server relationship. In the case of a 
10 client/server relationship, the server may “publish” its port 
in an appropriate place on the system. The client looks up 
this port and then uses it to initiate the bootstrap-meta- 
protocol described above. 

The establishment of a connection defines only the first 
15 proxy on each side. Proxies for any other objects that need 
to be communicated are created dynamically as they are 
encountered. For example, if a remote method returns a new 
object, a new proxy is created when decoding the result 
locally, such that the local program could send a message to 
20 this new remote object without any explicit setup. 

Once a connection is established, a message may be sent 
(in either direction). To send a message, the arguments must 
be encoded into a form that is representable in a Mach 
message, so that the receiver may decode them correctly. To 
25 do this, the sender must know the method signature of the 
message. The method signature is part of the “protocol” that 
both sender and receiver must understand in order to com- 
municate, and is a domain-independent encapsulation of the 
method name, its argument types, and its return value type. 

Although a protocol may be arranged by prior agreement 
in many cases, the present invention determines the protocol 
dynamically by asking the receiver how to encode the 
arguments for each message as it is encountered. During the 
35 first attempt to send a given message to a remote object, the 
local domain consults the remote domain to get the signature 
corresponding to the actual class implementation that will 
ultimately receive the message. This method signature is 
cached on a per-connection basis, with the assumption that 
40 the class of a remote object will not change for the duration 
of the connection. Thus, subsequent messages use the 
cached signature, and do not have the overhead of this 
“meta-protocol” transaction. This dynamic aspect is useful 
for type checking, and allows one program to “learn” how 
45 to talk to another program. 

The argument encoding for standard C data types is 
explicit and strictly pass-by-value, and maps substantially 
directly onto a Mach message. Pointers to C data structures 
are not encoded. Arguments that are first-class objects (as 
50 opposed to simple C data types) are handled specially; they 
are asked to encode themselves. The default encoding 
scheme that most objects inherit is to allocate a token (if one 
does not already exist) in the local domain, and encode only 
that token. Along with the port of the local domain, this 
55 constitutes an object reference (via proxy), and when it is 
decoded on the receiving side, results in a new proxy for that 
remote object. 

Thus, first-class objects by default get passed by reference 
instead of by value. For example, when domain A sends a 
60 message with object X as an argument to a remote object in 
domain B, a new proxy is created in domain B to represent 
X. Any subsequent message that domain B sends to X results 
in another remote object transaction. In the present inven- 
tion, an implementation of an object class is free to choose 
65 to implement a different encoding scheme, for example one 
that encodes the object by value, though this requires that 
both sender and receiver implement that class of object. The 
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“pass-by-proxy” scheme does not have this restriction and is 
generally preferred. 

Because objective C implements functional messages, a 
return value is always returned in a reply message. It is 
encoded exactly the same way as arguments are. In particu- 5 
lar, if the result is an object or a proxy, it is encoded as a 
proxy or an object, respectively, in the other domain. The 
reply message also encodes information about errors or 
exceptions that may have occurred, so that they can be raised 
in the local context. That is, an error occurring while 10 
executing a message sent to a remote object is caught and 
returned to the caller, so that the exception is raised in the 
local domain. This makes error handling transparent. 
Remote exceptions may be handled the same way as local 
exceptions. 15 

The use of a single port to represent a domain of objects 
allows an efficient and simple implementation. A one-way 
message is used when forwarding a message to a remote 
domain. Messages are received on the local domain’s single 
published port while waiting for the reply. Since all mes- 20 
sages (including both the reply message and any other 
messages initiated from remote domains) arrive on the same 
port, each one can be handled serially. There is no global 
state to keep track of (the logic is implemented in a re- 
entrant manner), and each message and reply have matching 25 
sequence numbers, so it can be determined when the correct 
reply has been received. 

In effect, the low level routine to actually forward the 
message to the remote domain becomes the main loop of the 3Q 
program until the reply is received. There may be many 
nested levels of this low level routine at one time. Outside 
the scope of a locally-initiated remote message (i.e., the 
“idle” state of waiting asynchronous messages to arrive), the 
local domain’ s port is listened to by the main program, along 35 
with other non-remote-object related events. This approach 
contrasts with that of the prior art McCullough system, 
where a process or thread is forked to field every expected 
reply. The present invention achieves an order of magnitude 
in performance by avoiding the forking when communicat- 4Q 
ing. 

An example of a computer program listing that may be 
used to implement the present invention is described in 
Appendix A. This computer program listing is given by way 
of example only. The present invention may be practiced 45 
using other programs and methods as well. 

Automatic Forwarding of Messages 

The present invention, in its preferred embodiment, takes 50 
advantage of a method referred to as “automatic forwarding 
of messages.” This method is the subject of copending 
patent application Ser. No. 07/695,316 filed May 3, 1991, 
entitled “METHOD FOR PROVIDING AUTOMATIC 
FORWARDING OF MESSAGES AND METHODS” and 55 
assigned to the assignee of the present invention. This 
method is described below. 

In objective C, when an object receives a message that 
contains a method that the object does not recognize, an 
exception is provoked leading to an error. The present 60 
invention, instead of provoking an exception, redirects the 
message to an acquaintance that can understand the mes- 
sage. For example, if an object receives a message contain- 
ing a method that the receiving object does not contain, the 
message is forwarded to an acquaintance object that does 65 
contain the method. This provides the advantage of inher- 
iting the method from the acquaintance object but does not 
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require the first receiving object to actually have the method 
itself. This reduces code size the memory requirements. 

The present invention has a plurality of uses. For 
example, a new object class can be defined so that one of its 
instances (attributed object) adds an attribute to another 
object (its forwardee). In that situation, automatic forward- 
ing occurs when an attributed object receives a message that 
is irrelevant to the attribute, and the method is forwarded to 
the forwardee. In another situation, some functionality is 
applied before and/or after the forwarding. This can be used 
in the case of a locking data structure where all methods 
must be redirected to the locked data after acquiring the 
lock, and where the lock must be released after the execution 
of the forwarded method. The present invention also has use 
in the case of forwarding messages in a distributed envi- 
ronment where there is no explicit forwardee. Rather, there 
is a network address of the forwardee. 

The implementation of the present invention in the pre- 
ferred embodiment requires trapping the “message not rec- 
ognized” exception of objective C, retrieving all of the 
arguments of the unrecognized message, and sending the 
“forward::” message to the object. 

The resulting automatic forwarding system of the present 
invention is more powerful than multiple inheritance and is 
transparent to the programmer and developer. The system is 
general, because the forwardee is not explicit, thus permit- 
ting solutions to a large class of problems. 

The present invention uses the forward:: command so that 
subclasses can forward messages to other objects. The 
format is forward: (SEL) aSelector:(marg_list) argFrame. 
When an object is sent an aSelector message, and the run 
time system cannot find an implementation of the method 
for the receiving object, the run time system sends the object 
a forward:: message to give it an opportunity to delegate the 
message to another object. If the forwardee object cannot 
respond to the message either, it also has the opportunity to 
forward the message. A forward:: message is generated only 
if a selector method is not implemented by the receiving 
object’s class or by any of the classes it inherits from. 

The forward:: message thus allows an object to establish 
relationships with other objects that will, for certain mes- 
sages, act on its behalf. The forwarding object is, in a sense, 
able to “inherit” some of the characteristics of the object it 
forwards the message to. The forwarding object is not 
limited to the forwardees it may select, and a forwardee 
relationships may be formed with more than one object at 
the same hierarchical level. Therefore, the present invention 
provides the advantages of multiple inheritance without the 
code size problem. 

In addition to forwarding messages, the forward:: method 
can locate code that responds to a variety of different 
messages, thus avoiding the necessity of having to write a 
separate method for each selector. 

If implemented to forward messages, a forward:: method 
has two tasks. First, to locate an object that can respond to 
the aSelector message (this need not be the same object for 
all messages). Second, to send the message to that object 
using the performv:: and performv method. 

The operation of the present invention is illustrated in the 
flow diagrams of FIG. 5. At step 501, Object A sends an 
aSelector message to object B. At decision block 502, the 
argument “Implementation exists in Object B?” is made. If 
the argument is true, the method of the aSelector message 
can be executed by object B. If that is the case, the system 
proceeds to step 503 and the method is executed. If the 
argument is not true, the system proceeds to step 504 and 
invokes the forward:: method. 
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The forward:: method then performs the first of its two 
tasks at step 505 . Namely, it attempts to locate an object to 
respond to the aSelector message. At decision block 506 , the 
argument “Object found?” is made. If the argument is true, 
then forward:: has successfully found an object to respond to 
the aSelector message. In the present invention, the forward- 
ing object is typically a proxy object. 

The system then proceeds to step 507 , the message is 
encoded and transmitted as an operating system message to 10 
another process. At step 508 , the operating system message 
is decoded and provided to the destination object. At step 
509 , the destination object executes the method of the 
message to generate a result. At step 510 , the result is 15 
encoded and transmitted to the first process as an operating 
system message. At step 511 , the message is decoded and the 
result is provided to the sending object. 

If the argument at decision block 506 is not true, the 2Q 
system proceeds to decision block 512 . At decision block 
512 , the argument “forward again?” is made. If the argument 
is true, the message is forwarded again and a search for an 
object to respond to the message is made. If the argument is 
false, the system proceeds to step 513 and an exception 25 
(error) is invoked. 

In the case in which an object forwards messages to just 
one destination, a forward:: method could appear as follows: 


- forward: (SEL)aSelector :(marg_list)argFrame 
{ 

if ([friend respondsTo:aSelector|) 

return (friend performv:aSelector:argFrame}: 
return [self doesNotRecognize:aSelector]; 

1 


ArgFrame is a pointer to the arguments included in the 
original aSelector message. It is passed directly to per- 4Q 
formv:: without change. The default version of forward:: 
implemented in the object class invokes the does not rec- 
ognize: method. It does not forward messages. Thus, if a 
user chooses not to implement forward:: methods, unrecog- 
nized messages will be handled in the usual way. 


The objective C run time code routines for implementing 
automatic forwarding of messages is as follows: 


// provide a default error handler for unrecognized messages 
static id-forward (id self, SEL sel, . . .) 

{ 

id retval; 

// the following test is not necessary for Objects (instances of 
Object) 

// because forward:: is recognized, 
if (sel =@ selector (forward::)) } 

_objc__eiror (self, _errDoesntRecognize, SELNAME 

(sel)); 

return nil; 

} 

retval =lself forward: sel : &selfj; 
return retval; 

{ 

Method smt =(Method) objc_malloc (sizeof (struct 

objc__method)); 

smt->method_name sel; 

smt->method_types = 

smt->method_imp = (IMP)_forward; 

_cache_fill (savCls, smt); 

i 

i 

Method smt = (Method) objc_malloc (sizeof (struct 
objc_method)); 
smt->method_name = sel; 
smt->method_types = 
smt->method_imp = (IMP)_forward; 
cache„fill (savCls, smt); 

1 

// the class does not respond to forward: (or, did not supply a 
dest) 

1 

Method smt = (Method) objc_malloc (sizeof (struct 

objc_method)); 

smt->method_name = sel; 

smt->method_types = 

smt->method_imp = (lMP)_forward; 

_cache_fill (savCls, smt); 

} 

return (IMP)_forward; 


Thus, a method and apparatus for providing distributed 
processes is described. 
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APPENDIX A 


ff import 
((impart 
K import 
if import 
((import 


<stdlib.h> 
<stdarg.h> 
<objc/HashTable .h> 
cob j c /hash table . h> 
<sys/message . h> 


/* Declarations that will go away */ 
extern SEL _sel_registerName (STR key); 

/****************. Definitions ***.*«**..*******.****».*./ 


extern int deEaultCommTimeout ; /* in millisecs, <0 means infinite */ 

extern int reinoteMessageReceiveCount; /* increments when a msg is received */ 

/* The following type of function may be passed to the beginListeningOn : rootObject : m 

ethod. It gets asynchronously called during remote message sending. For example, an app co 
uld register the port and function with DPSAddPort when the boolean is YES (and DPSRemoveP 
or t when NO) . * / 

typedef void ( *remote_message_handler_t ) (msg_header_t *msg, void *userData) ; 

typedef void ( *receive_enable_proc_t) (port_t port, remote_message_handler_L fun, BOOL shou 
IdEnable) ; 


typedef enum ( 

((define REMOTE_EXCEPTION_BASE 36000 /* less than appkit base */ 
/* Format of exceptions is a label and a message string */ 
GENERIC_REMOTE_EXCEPTION = REMOTE_EXCEPTION_BASE, 

T 1 M EOUT_R EMOTE_EXC E PT1 ON , 

LAST_REMOTE_EXCEPTION 
) RemoteException; 




Communication 


★ A************************ J 


@ interface Communication; Object ( 

@public 

port_t sendPort; 

int timeout; /* in milliseconds */ 

NXliashTable *objectsGivenAway; 

NXHashTable ‘allProxies; 

} 

+ beginListeningOn: (port_t) listenPort enableProc: (receive_enable_proc_t) aProc; 
/* Initialize the remote object system. 

enableProc is called immediately with a boolean of YES. */ 

+ new: (port_t) port timeout : (int) aTimeout; 

+ f indCominForPort : (port_t) aPort; 


Send 


/ 


»******4**<nHi**** 


Remote Objects 


*******+**** + *★******#**■** 


/ 


(Sinter face RemoteObject: Object { 

Communication *comrc; /* nil means “local" */ 

unsigned name; /* object name; 0 means localRoot */ 

HasliTable *knownSelectors; /* cache */ 

) 


+ niessageReceived: (msg_header_t *)msg; 
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+ newRemote : (unsigned) remoteName withCommunication: (CoiranunicaLion *) communication; 
/* Tills is used only for bootstrap */ 

+ registerLocalRoot : root ; 

/* Register the local root, and return a remote object with name 0; 

Can only be called once */ 

+ newLocal : local withCommunication: (Communication * ) communication; 

/* search for a local -RemoteObject that corresponds to local id. 

If none found, creates one */ 

- (unsigned) remoteObjectName; 

- (unsigned) methodArgSize : (SEP) sel; 

/* Size of tlie arguments of the remote object, including self and sel; 

0 iff error */ 

- forward: (SEP) sel : (void *) args; 

Send 


/***************** Encoding Protocol 


************************** / 


Sinterface Object (Object_MakeRemote) 

- encodeliemotelyFor : (Communication *) communication f reeAf terEncoding : (BOOP *)£lag; 

/* This inetliod is called for each object being encoded; By default, it consists in ere 
atiug a new "local" remote object (i.e. passing the object by reference). To pass the obj 
ect by value, just return the object. To substitute another object, just return it. 

Iff flag is set, the returned object will be freed after encoding. */ 


- afterl'orLReading : (Communication *) communication, 

/* Tliis method is called after decoding an object to give an opportunity to replace it 
; original object can be freed */ 


- instantiateObject: (const char *)className; 

- setOutlet : (const char * ) outletName withidest; 
Send 
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H import "Remoteobject . h * 
((import "WXPorLStream.h" 


ft import <string.li> 

(I import <stdio.h> 

Ifimport <libc.h> 

Ifimport <cthreads.h> 

# import <macli.h> 

((import <syelog.h> 

If import- <objc/error .h> 

Ifimport <objc/List.li> 
ifimport <objc/objc-runtime.h> 
Ifimport <kern/mach_param.li> 

If import <sys/message .h> 


/»»**»***»**»***** Forward Definitions 


**************************/ 


static void lianclleReinoteMessage (msg_header_t *m, void ‘userUata) ; 
static void remoteAsk (port_t port, msg_header_t *msg, int timeout); 
flif 0 // Never tried 

static void remoteTell (port_t target, msg_lieader_t ‘msg, port_t sender, int timeout); 
ff end.i f 


/***************** Utilities 


**************************/ 


int defaultComm'I’imeout = 15000; 

BOOL enableWarning = NO; 

static void logvf const char ‘format, va_list args) ( 
print f ( "RemoteObjects [pid %dj:\f, getpidO); 
vprintC (format, args); 

) 

static void ROLoy (const char ‘format, ...) { 
va_list args; 

va_start (args, format); 
iogv( format, args); 
va_end(args) ; 

) 

static void warning (const char ‘format, ...) { 
va_list args; 

va_start (args , format); 
if (enableWarning) logv(format, args); 
va_end (args) ; 

) 


static void error (const char ‘format, ...) { 

va_list args; 
va_start (args, format); 
logv ( format , args ) ; 
va_end(args) ; 

NX_RAISE(GENERIC_REMOTE_EXCEPTION, "Internal error", NULL); 

) 

static int generateSequenceNumberl) ( 
static int number=0; 
number+i ; 

if ('number) number = 1; /* useless */ 
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return number; 

) 


S interface Object (Private_Imports) 
- reallyFree; 

Send 


/***************** 


Selector Info ««**....******♦*"***"*****'/ 


@interface RemoteMetliodlnfo: Object [ 
NXAtoin typedesc; 

} 


static RemoteMetliodlnfo "knownRemoteMethodlnfo = nil; 

> localHethodlnfoFor : (Class) class : (SEL) sel; 

/* Return RemoteHethodlnfo for a local method; 

Can return nil */ 


- encodeMethodParams ; (void *)args onto: (NXPortStream *)stream; 

/* encode the method frame onto stream (excluding self and sel) */ 

- (void *) decodeMethodParamsFrom: (NXPortStream "(stream; 

/* decode ttie method frame from stream; 

return a freshly malloced pointer, never NULL (unless error) */ 

- encodeMethodRet : result onto: (NXPortStream *)stream; 

/" encode the method return value */ 

- decodeHethodRetFrom: (NXPortStream *) stream; 

/* decode the return value. */ 


- (unsigned) sizeOfParams ; 

/* Return the size of all parameters including self and sel */ 

@end 

(^implementation RemoteMetliodlnf o 

static unsigned hasliHetliodlnfo (const void "info, const void "data) ( 
const RemoteMetliodlnfo *rm - data; 

return (unsigned) rm->typedesc; /* depends on the fact its uniqeud */ 

static int isEqualHethodlnfo (const void "info, const void "datal, const void *data2) ( 
const RemoteMetliodlnfo "rml = datal; 

const RemoteHethodlnfo *rm2 = data2; 

return ( rml->typedesc == rm2->typedesc) ; 

) 

static NXHashTablePrototype proto = (hasliHetliodlnfo, isEqualMetliodlnfo, NXNoEf fectFree, 0) 


static NXlIasliTable "allMethodlnfos = NULL; 

+ initialize { 

if (! knownRemoteMethodlnfo) { 

allMethodlnfos = NXCreatellashTable (proto, 0, NULL); 

knownRemoteMethodlnfo = (RemoteMetliodlnfo localHethodlnfoFor : (Class) (Object clas 
sj :Qselector (remoteMetliodlnfo: ) J; 

) 

return self; 

) 


+ localHethodlnfoFor: (Class)class : (SEL)sel { 

Method method = class_getInstanceMetliod(class , sel); 

RemoteMetliodlnfo "previous; 
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if (! method) { 

error!"*** localMethodlnfoFor: : for '%s' with '%s' return nil\n”, [(id) class name 
] , sel_getName ( sel ) ) ; 
return nil; 

) 

self = [super new] ; 

typedesc = NXUniqueString (method->method_types) ; 
previous = NXIIashGet (allMetliodlnfos, self); 
if (previous) {[self free); return previous; ) 

NXIlashlnsert (allMethodlnfos, self) ; 
return self; 


- encodeRemotelyFor: (Communication *) communication freeAf terEncoding : (BOOL *)flag ( 

return self; 

) 

- writePortStream: (NXPortStream *) stream { 

[super writePortStream; stream]; 

warning ( "writing a Method; %s\n” , typedesc); 

NXWritePortTypes (stream, atypedesc) ; 

return self; 


- readPortStream : (NXPortStream *) stream ( 

(super readPortStream: stream]; 

NXReadPortTypes (stream, ■%”, stypedesc) ; 
warning ( "reading a Method: %s\n" , typedesc); 
return self; 

) 

- encodeMethodParams : (void *)args onto: (NXPortStream ‘(stream ( 

struct objc_method met; 
unsigned nb; 

unsigned index = 2; /-* skip result, self and sel */ 
int offsetO; 

char ‘type; 

met .metliod_types = (char *) typedesc; 
nb = metliod_getNumberOf Arguments (Smell ; 

NXWritePortTypes (stream, “i", &nb) ; /* just for redundancy */ 
method_getArguinenUInfo (&met, 0, &type, ioffsetO); 
wliile (index < nb) { 

char *type; 

int offset = 0; 

void *arg; 

metliod_getArgumentlnfo (4met , index, Stype, toffset) ; 

if (! offset) error!"*** encodeMethodParams: onto: cannot extract %d argument for t 
ype desc %s\n", index, typedesc); 

arg = ( (char * ) args) +of f set-of fsetO; 

warning ( "encodeMethodParams : onto: type=%s value=0x%x\n“ , type, ‘(void **)arg); 

NXWritePort’lypelnternal (stream, type, arg); 

index++; 

) 

return self; 


- (void * ) decodeMethodParamsFrora : (NXPortStream *)stream [ 
struct objc_method met; 
unsigned nb; 

unsigned index = 2; 
unsigned count; 

void *args; 

int offsetO; 

char ‘type; 
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iiH 3 l.mal.lioil_(.ypesi = (char *> typedesc; 
nb = method_getNumberOfArgunients (&met) ; 

HXReadPortTypes (stream, "i", &count) ; 
if (count != nb) { 

error ( "decodeMethodParamsFrom: incompatible method parents"); 
return NULL; 

) 

inethod_getAryumentInfo (&met, 0, &type, AoffsetO); 
args = calloct (self sizeOf Parains J , 1); 
while (index < nb) ( 

char ‘type; 

int offset = 0; 

void *arg; 

inethod_yetArgumentIn£o (Smet , index, Srtype, toffset) ; 

if (! offset) error ( " “* decodeMethodParanisFrom: cannot extract %d argument for ty 
pe desc tsln", index, typedesc); 

arg - { (cliar * ) args) +of fset-offsetO; 

NXReadPortTypelnternal (stream, type, arg); 

warning ( "decodeMethodParamsFrom: type=%s value=0x%x\n" , type, ‘(void **)arg); 
iudex+i ; 

) 

return args; 


- encodeMethodRet : result onto: (NXPortStream *) stream { 

//?? -> SN: way to get return types? 

if ( typedesc [0] == 'v') return self; 
if ( typedesc! 0] == 'c') ( 

//?? BOGUS, of course 

NXWritePortTypelnternal (stream, "i“, ((result) ; 

) else ( 

NXWritePortTypelnternal ( stream, typedesc, Sresult) ; 

) 

return self; 

) 


- decodef-lethodnetFrom: (NXPortStream *) stream ( 

id result = nil;/* important init. for result less than 4 bytes */ 

//?? -> SN: what Iff result more than 4 bytes? 
if (Lypedesc[0J == 'v') return nil; 

if (typedesctO) == 'c') { 

//?? BOGUS, of course 

NXReadPortTypelnternal (stream, "i*, &result); 

) else ( 

NXReadPortTypelnternal (stream, typedesc, sresult) ; 

) 

return result; 

) 


- (unsigned) sizeOf Params { 

struct objc_rnethod met; 

met ,method_ types = (char *) typedesc; 

return method_getSizeOf Arguments !&met ) ; 

) 

Send 

((interface Object (Object_RemoteMethodInfo) 

- remoteMethodlnfo: (SEL) sel; 

Send 

((implementation object IObject„RemoteMethodIn£o) 

- remoteMethodlnfo : (SEL) sel { 
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return l HemoteMethodlnfo localMethodln I'oFor : (Class) [ self class! :sel]; 

) 

Send 


^ + ik * * * * * * * ***^**i4 


Communication 


*********************/ 


^implementation Communication 


typedef struct _LocalToRemote { 
id local; 

RemoteObject ‘remote; /* remote->name == (unsigned) local */ 

) LocalToRemote; 

static void freeLocalToRemote (const void ‘info, void ‘data) { 

LocalToRemote *ltr = data; 

I ltr->remote reallyFree] ; 
free (data) ; 

) 


static NXIlasliTablePrototype proxyProto; 
static id commList = nil; 

static receive_enable_proc_t enableProc = NULL; 
static port_t replyPort = P0RT_NULL; 

+ bey inbisteningon : (port_t ) listeuPort enableProc : (receive_enable_proc_t ) aProc ( 
replyPort = listeuPort; 

port_set_backlog (task_self () , listenPort, PORT_BACKLOG_MAX ) ; 
enableProc = aProc; 

if (enableProc) (‘enableProc) (replyPort , UandieReinoteHessage, YES) ; 
return self; 

) 

+ new: (port_t) port timeout : (int) aTimeout ( 

NXflasliTabiePrototype protol = NXPtrStructKeyPrototype ; 

protol. free - freeLocalToRemote; 

if (! conunList) commList = (List new) ; 

self = [super new); 

sendPort = port; 

timeout = aTimeout; 

objectsGivenAway = NXCreateHashTable (protol , 0, NULL); 
allProxies = NXCreateHashTable (proxyProto, 0, NULL); 

(commList addobject :sel£J ; 
return self; 


+ findCommForPort : !port_t) aPort ( 
int index = [commList count) ; 
while (index--) 

if (((Communication *) [commList objectAt : index) ) ->sendPort == aPort) 
return (commList objectAt : index) ; 
return nil; 

) 


- Tree ( 

[commList removeObject:self ] ; 
NXFreeliasliTable (objectsGivenAway) ; 
HXFreellashTabie ( allProxies ) ; 
return [super free); 


- beforeEucoding: object onto: (NXPortStream *)stream freeAfterEncoding: (BOOL *)flag { 
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, e i. urn lobject encodeRemotelyFor : streaiu->cunimunicatioii CieeAI terEncoding : f lag ) ; 

) 


- afterDecodingrobject from: (NXPortStream *) stream ( 

reLurn (object afterPortReading: stream->communication) ; 

) 


@end 

y******* ********** 


Remote Objects 


A*********************** - **/ 


static id iocalRoot = nil; 

static id localRemoteForRoot = nil; 

@ imp 1 eme n t a t i on Remo teObject 

+ initialize { 

/* we have to initialize knownRemoteMethodlnfo! */ 

(RemoteMethodinfo initialize] j 
return self; 

) 

+ newRemote : (unsigned) remoteName withCoimuunication: (Communication *) communication { 
sell = [super new]; 
comm = communication; 
name = remoteName; 

if (NXHashlnsert (communication->allProxies, self)) error ( "newRemote: already m table 

“) ; 

return self; 

) 

+ newLocal : local withCommunication: (Communication * ) communication ( 

Loca I'I'oRemote pseudo; 

Locai'i'oReinote *ltr; 

j.f (I local) return nil; 

if (local == IocalRoot) return localRemoteForRoot; 
pseudo. local = local; 

lt:r * NXIIasliGet (communication->objectsGivenAway , Spseudo) ; 

if (ltr) return ltr->remote; 

ltr = malloc (sizeof (LocalToRemote) ) ; 

ltr->iocal = local; 

itr->remote = [self new] ; 

Xtr->remote->name = (unsigned)local; 

NXHashlnsert (comrauiiication->objectsGivenAway, ltr) ; 
return ltr->remote; 


+ registerLocalRoot : root ( 

if (IocalRoot) error ( "registerLocalRoot : root registered twice!"); 
IocalRoot = root; 

return (localRemoteForRoot = [self new] ) ; 


+ messageReceived: (msg_header_t *)msg { 
liaudleRemoteHessage (msg, NULL) ; 
return self; 


- reallyFree { 

[knownSelectors free); 
return [3uper free] ; 

) 


free ( 
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I ,>u(l,OG_i:i!R, "Remote Object 0x1>x loceivod Lieu", sell); 
letuiu nil; 

) 

static unsigned hashProxy (const void ‘info, const void ‘data) { 
return { (RemoteObject * ) data ) ->nanie; 

} 

static int isEqual Proxy (const void ‘info, const void ‘datai, const void *data2) { 
return ((RemoteObject *) datai) ->name == ((RemoteObject *)data2) ->name; 

) 

static void freeProxy (const void ‘info, const void 'daLa) { 

[(id)data reallyFree] ; 

) 


static NXIIashTablePrototype proxyProto = (hashProxy, isEqualProxy, freeProxy, 0); 

- (unsigned) remoteObjectHame { return name; ) 

- remoteMethodinfo: (SEL) sel ( 

id res ; 

id args [4] ; 

if (sel -- 8 selector (remoteMethodinfo: ) ) return knownRemoteMethodlnfo; /* to avoid inf 
inite recursion */ 

res = 1 knownSelectors valueForKey: (void *)selj; 
if (res) return res; 

//?? -> SN How to fill args cleanly 
bzeroiargs, sizeof ( id) *4 ) ; 

Method method = class_getInstanceMethod( (Class) [Object class) , Sselector (remoteMe 
thodlnfo : ) ) ; 


char 

‘type; 

int 

o££sel2; 

int 

offsetO; 

SEL 

•ref; 


method_getArgumentIn£o (method, 0, Stype, SoffsetO); 
meLhod_getArgumGntInfo (method, 2, &type, Soffset2) ; 
ref = (SKI, *) (((char * ) args) lorfsetX-offsetO) ; 

‘ref = sel; 

) 

res = 1 (id) self forward: Sselector (remoteMethodlnfo: ) :arys ) ; 
if ( I knownSelectors) knownSelectors = [MasiiTable newKeyUesc ; " ; • ] ; 
IknownSefectors insertKey : (void *)sel va.lue:resj; 
return res; 


- encodeHemotelyFor : (Communication *) communication f reeAf terEncoding ; (BOOL *)£lag ( 
return self; 

) 


- writeFortStreara; (NXPortStream *) stream ( 

[super writePortStream: stream]; 
HXWritePortiypes (stream, "ii", icoian, Suiame) ; 
return self; 

J 


- readPortStream: (NXPortStream *) stream { 

(super readPortStream: stream); 
NXReadPortTypes (stream, "ii“, tcomm, (name) i 
return self; 

) 


- afterPortReading: (Communication *) communication { 
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iL ( ! cumin ) { 

id previous; 

/* it was local for the other guy */ 

warning (" in af terPortReading - read Remote %d\n", name) ; 
comm = communication; 

previous = NXIIashGet (communication->allProxies, self); 
if (previous) { 

warning ( “receiving same name=Ox%x previous=(Jx%x self=0x%x\n", name, previous, 

self) ; 

(self reallyFree]; 

return previous; 1 

) 

NXHashlnsert (communication->allFroxies, self) ; 
return self; 

) else ( 

I.ocalToReinote pseudo; 

LocalToRemote *ltr; 
pseudo. local = (id) name; 
if (! name) ( 

if (! localRoot) error ("invariant broken in af terPortReading :") ; 

[self reallyFree] ; 
return localRoot; 

) 

ltr = NXNashGet (communication->objectsGivenAway , 6pseudo) ; 
if (! ltr) error ( “af terPortReading; ") ; 
if ( (unsigned) ltr->local != name) ( 

error ( "af terPortReading ; broken invariant"); 

) 

warning (“in af terPortReading - converting Remote %d into local Ox%x\n“, name, ltr 

> local) ; 

(self reallyFree]; 
return ltr->local; 



(unsigned) methodArgSize; (SEL) sel ( 

RemoteMethodlnfo ‘selinfo = (self remoteHethodlnf o: sel) ; 
if (! sellnfo) return 0; 
return (selinfo sizeOfParams] ; 


- forward: (SEE) sel : (void *)args { 


char 

insg_.header_t 

NXAtom 

lilt 

NXPortStream 

RemoteHetliodinto 

id 

int 


buffer [MSG_SIZE_MAXJ ; 

*msg = (msg_lieader_t * (buffer : 

selName = NXUniqueString (sel_getName (sel)); 

sequence = generateSequenceNumber ( ) ; 

‘stream = NXOpenEncudePortStreamfmsg, sequence, 
•selinfo = [self remoteMetliodlnfossel]; 
result; 
errorCode; 


comm) ; 


if ( ! selinfo) error ( "forward: ; cannot find remote selector %s", selName); 
warning ( “entered forward:; self=%d selName=%s\n" , name, selName); 

NXWritePortTypes (stream, tself, SselName); 

[selinfo encodeMetliodParams:args onto : stream] ; 

NXG’loseEncodePortStreain (stream) ; 

warning["in forward:: - %d made packet for |0x%x comm:%x %s ...]\n", name, comm, self, 
selName) ; 


remoteAsk (comm->sendPort, msg, comm->Uimeout) ; 

/* let's decode the result */ 

warning("in forward:: selName=%s received answerin’, selName): 
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stream = NXOpenDecodePortStream {msg, conun) ; 

NXReadPort'l'ypes (stream, "i", SerrorCode) ; 

if (errorCodel error (" forward: : Error occurred during remote execution" ) ; 
result = [sellnfo decodeMethodRetFrom: stream! ; 

NXCloseDecodePortStream (stream) ; 

warning ("in forward:: - %d result decoded for [Oxtx conun: %x %s ...]\n", name, cdmm, se 
If, selName) ; 

return result; 

} 


Send 

Object Misc 

Sinterface Object (Object_MakeRemote) 

- setAction: (SEL) theSelector; 

Send 

@ implementation Object (Object_MakeRemote_Import) 

- encodeRemotelyFor : (Communication *) communication freeAf terEncoding : (BOOL *)flag ( 

warning ( “ill encodeRemotelyFor - converting local Ox%x (%s) into remote\n" , self, [self 
name ) ) ; 

return [RemoteObject newLocal :self withCommunication:communicaLion] ; 
i 

- after PorLReading: (Communication * ) communication { 

return self; 


- iustantiateObject : (const char *)className ( 

return i objc_geLClass ( (char * ) classNaine) new); 

1 


- seLOutlet : (const char *)outletName wilh:dest ( 
char metliodString! 256 ] ; 

SEL sel ; 

strcpy (metliodString, "set " ) ; 
strcat (metliodString, outletName) ; 
strcat (methodstring, ":*); 

if (metliodString [3 ] >= 'a' && methodstring [3] <= ’ z ') 
metliodString (3 J += 'A' - 'a'; 

sel = _sel_registerName ( (char *)NXUniqueString(methodString) ) ; 
llif 0 

if ([self respondsTo : sel ] ) ( 

[self per£orm:sel with:dest]; 

) else ( 

object_setInstanceVariable(self , metliodString, dest); 

) 

((else 

[self perform : sel withidestj; 

Hendif 

return self; 

) 


Send 

/.*.*. **..**.**... Message transport *.*.*.*.***..*.**.**..*** + / 

((define RO_TELL_MSG_ID (232323) 

Hdefine RO_ASK_MSG_ID (323232) 
lldefine RO_REPLY_MSG_ID (233223) 

lldefine DEFAULT_TIMEOUT (15000) 

static void remoteReply (port_t rPort, msg_header_t *msg, int timeout); 
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static void JiaiidleReinoteAsk (msg_header_t *msy, port_t sender, id communication) { 
/* 


“ perform a remote RPC. 

“ This function may call many callouts to enableReinoteListening and 
“ di sableReraoteListening as it recurses. 

** exceptions may arise. 

*/ 


NXALom 

id 

NXPortSLreara 

char 

id 

SCO, 

int 

RemoteMethodlnfo 

int 

cliar 


selName; 

volatile result = nil; 

‘stream = NXOpenDecodePortStreain (msg, communication); 

‘args; 

self; 

sel; 

errorCode = 0; 

‘sellnfo; 

sequence = NXGetPortStreamSequence ( stream) ; 
buffer [MSG_SIZE_MAX] ; 


warning C in remoteAnswer received packetXn"); 

NXReadPortTypes (stream, &self, fcselName) ; 

warningCin remoteAnswer selName=$sXn" , selName); 
sel ^ se.l_getu.id ( (char *) selName); 

if (! sel) error ( "handleRemoteAsk: received message with unknown sel"); 

sellnfo = [self remoteMethodlnfoisel) ; 

args = [sellnfo decodeMethodParamsFrom: stream) ; 

NXCloseUecodePortStream (stream) ; 

if ( ! args) ( errorCode = -2; goto done; ) 

NX_DUR1NG 

result = objc_msgSendv (self , sel, [sellnfo sizeOfParamsJ , args); 

NX_IIANDPER 

R0Pog("“* Error while excutirig remote message for [0x%x %s . ..]\n", self, selName 

) ; 

errorCode = -1; 

NX_ENIJI1ANDLER; 
free (args) ; 

/* let's encode the result */ 
done: 

/‘we cannot reuse msg here, regrettably, because if we come from DPSClient, we don't 
have an 8K buffer but a copy only big enough for the incoming msg; sigh */ 
insg = (msy_header_t * ) buffer ; 

stream = NXOperiEucodePortStream (msg, sequence, communication); 

NXWri LePortTypes (stream, “i“, SerrorCode! ; 

(sellnfo encodeMetliodRet : result onto: stream] ; 

NXCloseEncodePor tstream (stream) ; 

remoteReply ( sender , msg, ( (Communication* ) communication) ->timeout ) ; 
warning ( "in remoteAnswer made return packetXn"); 


static void handleRemoteTell (msg_header_t *msg, port_t sender. 


const char 
NXPortStream 
char 

id 

SEP 

int 

RemoteMethodlnfo 


‘selName; 

‘stream = NXOpenDecodePortStream (msg, 

‘args; 

self; 

sel; 

volatile errorCode = 0; 

‘sellnfo; 


id communication) 
communication) ; 


{ 


warning ( "in handleRemoteTell received packetXn"); 

NXReadPortTypes (stream, "0%", Sself, sselName) ; 
warning ("in handleRemoteTell selName=%s\u" , selName); 
sel * sel_getuid ( (char *) selName); 

if (! sel) error ( "handleRemoteTell : received message with unknown sel"); 
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selinfo = (self remoteMethodlnfo : sel ] ; 

args = [sellnlo decodeMethodParamsFrom: stream] ; 

NXCloseDecodePortStream (stream) ; 

it (! args) ( errorCode = -2; goto done; ) 

NX_OUIUNG 

objc_msgSendv (self , sel, (selinfo sizeOf ParainsJ , args) ; 

NX_IIANDLER 

errorCode = -1; 

NX_EMDHANDLER; 
free (args) ; 
done: 

if (errorCode) warning ("** * Error executing handlenemoteTell %d\n", errorCode); 


int remoteMessageReceiveCount = 0; 

static void handleRemoteMessage (insg_header_t *msg, void *userData) ( 
port_l sender = msg->msg_reinote_port ; 

id communication =’ (Communication f indComiiiForPort :sender] ; 

if (! conmiunication) ( 

syslog (L0G_ERR, "Received message from zombie"); 
return; 

) 

remoteMessageReceiveCount++; 
if (msg->rosg_id == RO_TEU,_MSG_ID) ( 

liandleRemoteTeli (msg, sender , communication) ; 

} else if (msg->msg_id == RO_ASK_MSG_ID! { 

handleHeinoteAsk (msg, sender, communication) ; 

) else 

syslog (L0G_ERR, "Bogus remote message"); 


dif 0 // Should work, but has never been used/tested 

static void remoteTell (port_t target, msg_header_t *insy , port_t sender, int timeout) ( 
int err, sndOptions = SEND_SWITCII; 

msg->msg_remote_port = target; 
msg->msg_local_port = sender; 
nisg-Miisg_id = RO_TELL_MSG_ID; 
if (timeout >= 0) 

sndOptions 1= SEND_T1ME0UT; 
err =■ msg_send(msg, sndOptions, timeout) ; 
if (err) error ( "remoteTell : cannot send"); 

) 

Jendif 

static void remoteReply (port_t rPort, msg_header_t *msg, int timeout) ( 
int err, sndOptions = SEND_SWITCH; 
nisg->msg_remote_port = rPort; 
msg->msg_local_port = P0RT_NULL; 
msg->msg_id = RO_REPLY_MSG_ID; 
if (timeout >= 0) 

sndOptions 1= SEND_TIMEOUT ; 
err = msg_send(msg, sndOptions, timeout) ; 
if (err) error ( 'remoteReply : cannot send”); 


static nestingLevel=0; 


static void remoteAsk (port_t target, msg_header_t *msg, int timeout) ( 
int err; 

int volatile sndOptions = SEND_SWITCH; 

int volatile rcvOptions = RCV_NO_SENDERS I RCV_INTERKUPT; 
msg->msg_remote_port = target; 
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msy • >insy_loca l_port = replyPort; 
msg->msg_id = RO_ASK_MSG_ID; 
if (Limeout >= 0) { 

sndOptions 1= SEND_TIMEOUT; 
revOptions 1= RCV_TIMEOUT; 

) 

nestingLevel++; 

if (nestingLevel == 1 && enableProc) 

( ‘enableProc) (replyPort, liandleRemoteMessage, NO) ; 
NX_DUJUNG 


err = msg_send(msg, sndOptions, timeout) ; 
if (err) error ( "remoteAsk: cannot send"); 
else ( 

while (1) ( 

nmg->msg_size = MSG_SIZE_MAX j 
insg->msg_local_port = replyPort; 
err = msg_receive(msg,rcv0ption9, timeout) ; 
if (err) ( 

ROLog (" remoteAsk : cannot receive or timeout\n" ) ; 
NX_RAISE(TIMEOUT_REMOTE_EXCEPTION, "Cannot receive”, 
I else { 

if (msg~>msg_id == RO_REPI,Y_MSG_l D) { 
break; 

) else 

liandleRemoteMessage ( (insg_)ieader_t *)msg, NULL) ; 
// 7 ? IF OUT OF LINE, DEALLOCATE MERE 

) 

) 

) 

nestingLevel -- ; 

if ( ! nestingLevel && enableProc) 

(‘enableProc) (replyPort , liandleRemoteMessage, YES) ; 

MXJ1AHDLER 

nestingLevel--; 

if ((nestingLevel && enableProc) 

( ‘enableFroc) (replyPort, liandleRemoteMessage, YES) ; 

NX_RKRAJ.SE { ) ; 

HX_ENUMANDLER; 


NULL) ; 


) 
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/* This module simply allows NXStrings to be passed across address spaces. 

The principle is: to encode a NXString, make a temporary object holding the string, encode 
its characters, free the temporary; to decode a NXString, decode the temporary object, re 
place by an immutable string, free the temporary. */ 

/(import ' . . /lowlevel . subproj /NXString. h" 

II import "KemoteObject .h" 

(/import "NXPortSLream.h” 

((import <string.h> 

((import <stdio.h> 

Sinterfaoe _TemporaryString!lolder : Object ( 

0 public 

NXString ‘string; 

) 

@end 

0 implementation _TemporaryStringHolder 

- wri tePortStream: (NXPortStream ‘(stream ( 

unsigned length = (string length]; 

MXCliar ‘chars = malloc ( length*sizeo£ (NXCliar) ) ; 

(super writePortStream: stream]; 

(string setChars : chars ] ; 

HXWritePortTypes (stream, "i", (length); 

NXPortFncodeBytes (stream, (char ‘(chars, length); 
free (chars) ; 
return self; 

) 

- readPortStream: (NXPortStream *) stream { 

unsigned length; 

NXCliar ‘chars; 

[super readPortStream: stream]; 

NXHeodPortTypes (stream, ”i", (length) ; 
cliars = mal Joe ( lengtli* sizeof (NXCliar (( ; 

NXPortDecodeBytes (stream, (cliar ‘(chars, lengtli) ; 
string = [NXImmutableString newFor: length charsicliars] ; 
free (cliars) ; 
return self; 


- after FortReading : (Communication *) communication ( 
NXString ‘res = string; 

(self free]; 
return res; 


Send 


Sinterface NXString (NXString_RemoteObject_Coding> , nru , T 

- encodeRemotelyFor : (Communication *) communication freeAf terEncodmg : (BOOL 

Send 


*) flag; 


Simplementation NXString (NXString_RemoteObject_Coding) 

- eiicodeRemotelyFor: (Communication *) communication freeAf terEncodmg : (BOOL (flag 
_Temporary St ring Holder ‘new = (_TemporaryStringHolder new] ; 
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new - >sUriiiy 
‘flag = YES; 
return new; 

} 

Send 


self ; 
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(f import cobjc/Object .h> 

# import <objc/iiashtable.h> 
((import <sys/message.h> 


extern SI5I. _sel_registerName (STR key); 
//?? will go away 


y**************A** 


Definitions 


**************************/ 


typedef struct _NXPortStream { 
msg__hea<3er_U *msg; 

//?? DO SIZE TEST LATER 

HOOL write,* /* writing vs reading */ 

id communication; 

char 'chars; 

i nt nbchars; 

int: maxchars; 

int *ints; 

int nbints; 

int maxints; 

) NXPortStream; 


//REMOVE AFTER DEBUG] 


^interface Object (Communication_Calis) 

- beforeEncoding; object onto: (HXPortStream *) stream freeAlterEncoding: (BOOL )flag; 

/* will encode the returned object: if flag is set, returned object will be send ' tree 
’ after encoding */ 

- at tor Decoding : object from: (NXrortStream *) stream; 

/* will replace the decoded object by the returned object *7 

Send 


I* *» *<**»***»*■«*** » global operations ******************* / 

extern HXPortStream *NXOpenEncodePortStreani(msg_header_t *msg, int sequence, rd coinmumcat 

ion) ; 

extern HXPortStream *NXOpenDecodePortStreain(msg_header_t *msg, id communication); 

/* butler is char [MSG_SIZE_MAX] ; 


If mode is NX WRITEONLY, creates a NXPortStream, ready for writing, given a Physic 
al stream on which to actually put the bytes. If mode is NX_ READONLY, f^esaNXPortStre 
am, ready for reading, given a physical stream on which to actually get the bytes. T 
Her is responsible for closing physical. If the file format mismatches right from the si 
art wi LI; stream format, NULL is returned, otherwise an exception might be raised. 


iff read, have buffers point to msg */ 

extern void NXCloseEncodePortStream(NXPortStream 'stream); 

/' Copy buffers into message and prepare msg for msg_send; 
free stream */ 

extern void NXCloseDecodePortStream(HXPortStream 'stream); 

/* free stream */ 


extern int NXGetPortStreamSequence (NXPortStream 'stream); 

Read/Write data .*,.*.**.***.*.*.*.*"""/ 

void NXForLEncodeBytes (NXPortStream 'stream, const cliar 'bytes, int count); 
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*/ 

llimport <objc/Object .li> 

II import: <objc/liashtable .h> 

H import <sy s/message. h> 

extern SEL _sel_regi sterName (STR key); 

//?? wili go away 

/**»**.****..****» Definitions **.♦****.*.*»»********'*"/ 


typedef struct _NXPortStream { 
msg_header_t *msg ? 

//?? DO SIZE TEST LATER 

1300L- write; /* writing vs reading */ //REMOVE AFTER DEDUGl 

id communication; 

char * chars? 

int nbchars ; 

int maxchars; 

int * ints? 

int nbints; 

.int maxints; 

) NXPorLStream; 


^interface Object {Communication_Calls) 

- beroreEncoding! object onto: (NXPortStream ') stream freeAf terEncoding: (DOOL *)flag; 

/* will encode the returned object; if flag is set, returned object will be send 'free 
' after encoding */ 

- afterDecoding: object from: (NXPortStream *) stream; 

/* will replace the decoded object by the returned object */ 

Send 


/****************** global operations 


***********************/ 


extern NXPortStream *NXOpenEncodePortStream(msg_header_t 'msg, int sequence, id communicat 
ion) ; 

extern NXPortStream *NXOpeiiDecodeFortStreain(msg_header_t *msg, id communication); 

/* buffer is char [MSG_SIZE_MAX] ; 

If mode is NX_WRITEONLY, creates a NXPortStream, ready for writing, given a physic 
al stream on which to actually put the bytes. If mode is NX_READONLY , creates a NXPortStre 
am, ready for reading, given a physical stream on which to actually get the bytes. The ca 
Her is responsible for closing physical. If the file Eormat mismatches right from the st 
art with stream format, NULL is returned, otherwise an exception might be raised. 


Iff read, have buffers point to msg '/ 

extern void NXCloseEncodePortStream (NXPortStream 'stream) ; 

/* Copy buffers into message and prepare msg for msg_send; 
free stream */ 


extern void NXCloseDecodePortStream(NXPortStream 'stream); 
/* free stream */ 

extern int NXGetPortStrearaSequence(NXPortStream 'stream); 


/***************** Read/Write data 


**************************/ 


void NXPortEncodeBytes (NXPortStream *etreain, const char *bytes, int count); 



53 


5,481,721 


54 


void NXPoi'LDecudeDytes (NXPortStream ‘stream, char ‘bytes, iut count); 

extern void NXWritePortTypes (NXPortStream ‘stream, const char ‘type, ...); 

/* Restricted to monochar type descriptions; 

bast arguments specify addresses of values to he written. 

It might seem surprising to specify values by address, but this is extremely conve 
n.ienL for copy-paste with NXReadPortTypes calls. A more down-to-the-earth cause for this 
passing of addresses is that values of arbitrary size is not well supported in ANSI C for 
functions with variable number of arguments. */ 

extern void NXReadPortTypes (NXPortStream ‘stream, const char ‘type, ...); 

/* Restricted to monochar type descriptions; 

bast arguments specify addresses of values to lie read. Expected type is checked a 
gainst the type actually present on the stream. */ 

extern void NXWritePortTypelnternal (NXPortStream ‘stream, const char ‘type, const void *da 
ta) ; 

extern void NXKeadPortTypelnternal (NXPortStream ‘stream, const char ‘type, void ‘data); 

errors ***.«*•**»********«•**»»••**/ 

/* several exceptions can occur; the format of all exceptions raised is a label, a message 
string and maybe some extra information */ 

Adeline I’OUTSTKEAM_ERROK_BASE 37000 /* less than appkit base */ 

typedef enum _PortStreamErrors { 

rORTSTREAM_CAt,LER_ERROR = PORTSTREAM_ERROR_BASE, 

PORTSTREAM_ INCONS I STENC Y , 

I’ORTSTH EAM_1NTERNAL_ERR01< 

) PortStreamErrors ; 

Ointerface Object (Object_PortStream_CallB) 

- writePortStreani! (NXPortStream *) stream; 

- reodPortSLream: (NXPortStream *) stream; 

@end 
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/* NXPort.SLream.m 

Copyriglit 1989, NeXT, Inc. 

Bertrand 1989 

*/ 

//import "NXPortStream. h’ 

/(import <stdlib.li> 

//import sstdarg.h> 

//import <stdio.li> 

((import <string.h> 
tfimport <syslog.h> 

/(import <mach.h> 

/) import <l.ibc.li> 
f) import <obj c/error. li> 

//import <objc/objc-class .h> 

(/import <objc/objc-runtime.h> 

//define DEBUG_LEAKS 0 

/***»*.*.***»****« Utilities **************** t ********* / 

static void BUG (const cliar *str) { 

syslog(l,OG_ERR, ““ RemoteObjects : internal error in %s", str); 
HX_RA1SE(P0RTSTREAM_INTERNAL_ERR0R, Str, NULL) ; 

) 


static void clieckExpected( const char ‘readType, const cliar ‘wanted) ( 
if (readTyP e == wanted) return; 

if (! readType II strcmp (readType, wanted)) BUG ( "checkExpected" ) ; 

) 


^implementation Object (Object_PortStream_Calls) 

- writePortStream: (NXPortStream *) stream { return self; ) 

- readPortStream; (NXPortStream *) stream { return self; ) 
Send 


y***H**M»M***** 


Def iniliions 


**********************♦***/ 


typedef struct _remote_message_t { 
insg_lieader_t header; 

msg_type_t sequenceType ; 

int sequence; 

/* following is chars type and chars, int types and ints, etc ... */ 
) remote_message_t ; 

static void PortlnternalWriteObject (NXPortStream ‘stream, id object); 

/* write an object without header V 
static id PortlnternalReadObject (NXPortStream ‘stream); 

/* read an object without header */ 


/***************** 


Coding data 


************************** / 


void NXPortEncodeBytes (NXPortStream ‘stream, const char *buf, int count) { 
while (stream->nbchars + count > stream->maxchars ) ( 
stream->maxchars += streain->maxchars + 1; 

stream->chars = realloc(stream->cliars, stream->maxchars) ; 

} 

bcopyfbuf, stream->chars + stream->nbchars, count); 
stream->nbchar8 += count; 

) 


void NXPortDecodeBytes (NXPortStream ‘stream, char *buf, int count) { 
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.if (count > streain->nbchars) BUG ! "NXPor LDecodeDytes “ ) ; 
bcopy (stream->chars, buf, count); 
strea>n->chars += count; 
stream->nbchars -= count; 

) 

static inline void _NXEncodeChar (NXPortStream ‘stream, signed char ch) { 
if (stream->nbc)iars + 1 > stream->maxchars) { 
stream->maxchars += stream- >maxchars > 1; 
slream->chars = realloc(stream->chars, stream->maxchars) ; 

) 

sLreain->chars [stream->nbchars ++] = ch; 

) 

static inline signed char _NXDecodeChar (NXPortStream ‘stream) ( 
if (stream->nbchars-- <= 0) BUG ( "_NXDecodeChar ” ) ; 
return * {streain->chars + + ) ; 

} 


static void _NXEncodeInt (NXPortStream ‘stream, int x) ( 
if ( sl:ream->nbints + 1 > stream->maxints) ( 
stream->maxints += stream->inaxints + 1; 

stream->ints = realloc (stream->ints, stream->maxints * sizeof (int) ) ; 

) 

stream->ints[stream->nbints++J = x; 

) 


static int _NXDecodeInt (NXPortStream ‘stream) { 

if (stream->nbints-- <= 0) BUG ( ”_NXDecodelnt" ) ; 
return * (stream->ints++) ; 

) 

static void _NXEucodeBool (NXPortStream ‘stream, BOOL x) { 
_HXi;ncodeInt (stream, (x) ? 1 : 0) ; 

) 

static BOOL _NXDecodeBool (NXPortStream ‘stream) ( 
int x = _NXDecodeInt (stream ) ; 

if (x && xi=l) BUG(*_NXDecodeBooi*) ; 
return x; 

) 

static inline void _NXEncodeFloat (NXPortStream ‘stream, float x) { 
NXPortEncodeBytes (stream, (char *) &x, sizeof ( float) ) ; 

) 


static inline float _NXDecodeFloat (NXPortStream ‘stream) ( 
float x; 

NXPortDecodeBytes (stream, (char *) &x, sizeof ( float) ) ; 
return x; 

) 

static inline void _NXEncodeDouble (NXPortStream ‘stream, double x) { 
NXPortEncodeBytes (stream, (char *) &x, sizeof (double) ) ; 

} 

static inline double _NXDecodeDouble (NXPortStream ‘stream) { 
double x; 

NXPortUecodeBytes (stream, (char *) &x, sizeof (double) ) ; 
return x; 

) 

static void _NXEncodeChars (NXPortStream ‘stream, const char *str) { 
_NXEricodeBool (stream, (str) ? YES : NO); 
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it (sir) ( 

ini len = strlen (str); 

_NXEncodeInt (stream, leu); 

NXPorlEncodeBytes (stream, i str, len) ; 

) 

) 

static char *_NXUecodeChars (NXPortStream ‘stream) { 
it (! _HXDecodeBool (stream) ) return NULL; 
else { 

int len = _NXDecodeInt (stream) ; 

char ‘str = (STR) malloc ( len+1 ) ; 

NXPortDecodeBytes (stream, str, len); 
str [len] = ' \0 ' ; 
return str; 

) 

) 

static NXAtorn _NXL)ecodeUnigueString (NXPortStream ‘stream) { 
char ‘new = _NXDecodeChars (stream) ; 

NXAtoin atom = NXUniqueString (new) ; 

tree ( new) ; 
return atom; 


/***.»** global operations **»*«**/ 

NXPortStream *NXOpenEncodePortStreamfmsg_header_t *msg, int sequence, id communication) ( 
NXPortStream ‘stream = calloc (sizeoE (NXPortStream) , 1) ; 

remoLe_message_t ‘iiead = (remote_message_t *)msg; 
if ( ! communication) BUG ( -NXOpenEncodeFortStream" ) ; 
strearo->coniiuunication = communication; 
streain->write = YES; 
stream->msg = msg; 

head->sequenceType . msg_type_name = MSG_TYPE_INTEGER_32 ; 
liead->sequericeType.msg_type_size = sizeof(int) * B; 

)iead->sequenceType.msg_type_number = 1; 
bead->sequence'iype.msg_type_inliue = TRUE; 
liead->sequence'iype.msg_type_long£orin = FALSE; 
head->sequeuceType.msg_type_deallocate = FALSE; 
liead->sequence = sequence; 

return stream; 

) 

NXPortStream *NXOpenUecodePortStream(msg_lieader_t *msg, id communication) ( 
vo i c l ‘head = ((void *)msg) rsizeof (remote_message_t) ; 

NXPortStream ‘stream = calloc ( sizeof (NXPortStream) , 1); 

if (! communication) BUG ( "NXOpenDecodePortStrearo” ) ; 
stream->communication = communication; 
stream- >write = NO; 
stream- >msg = msg; 

if (msg->msg_simple) ( 

msg_type_t ‘type; 

type = head; 

if (type->msg_type_name 1= MSG_TYPE_BYTE) 

BUG ( " NXOpenDecodePor tSt ream-char " ) ; 
ntream->nbc)iars = type->msg_type_uumber ; 

Iiead += sizeof (msg_type_t) ; 
stream->chars = head; 

Iiead += stream->nbchars; 
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type = head; 

if (l;ype->iiisg_type_n.ime != MSG_TYFE_INTEUER_32 > 

BUG { "NXOpenDecodePortStreain-inL “ ) ; 
slream->nbints = type->msg_type_number ; 
head i= sizeof (msg_type_t) ; 
stream->ints = head; 

head += stream->nbints * sizeof ( int) ; 

} else { 

msg_type_long_t ‘type; 

type = head; 

if (type->msg_type_long_narae != MSG_TYFE_BYTE) 

BUG { " NXOpenDecodePortSt ream-char " ) ; 
stream->nbcliars = type->msg_type_loiig_number; 
head += sizeof (msg_type_long_t) ; 
streaiu->chars = ((char *')head) (OJ ; 
liead i= sizeof (int); 

type = head; 

if ( ty pe- >msg_type_l ong_name 1= MSG__TYPE„INTEGER_32) 
BUG ( "NXOpenDecodePortSt ream- int * ) ; 
stream->nbints = type->msg_type_long_uuiiiber; 
head += sizeof (msg_type_long_t ) ; 
stream->ints = ( (int “(head) 10]; 
head += sizeof (int); 

) 

return stream; 


void NXCloseEncodePortStreamtNXPortStream ‘stream) { 

void ‘head = ((void * ) stream- >msg) rsizeof (remote_message_t) ; 

if { l stream->write) BUG ( "NXCloseEucodei’ortStream" ) ; 

/* We pad chars to a multiple of 4; what a hack! */ 

stream->nbchars = ( (stream->ubchars + 3)/4)*4; 

stream- >chars = realloc (stream->chars , stream->nbchars) ; 

/* We test for out-of-line */ , 

stream- >msg->ntsg_sirople = (sizeof (remote_message_t ) +sizeof (msg_type_t) +stream->nbchars 
i sizeof (insg_type_t) +stream— >nbints * sizeof (int) < MSG_SIZE_MAX) && (stream->nbchars <= 4 
95) && ( stream- >nbints <= 4095); 

if ( stream->msg->msg_simple) { 

msg_type_t ‘type; 

type = head; 

type->msg_type_nanie = MSG_TYPE_BYTE; 
type->msg_type_size = 0; 

Lype->msg_type_number = streaiu-jnbchars ; 

Lype->msg_type_inline = TRUE; 
type->insg_type_longform = FALSE; 

Lype->msg_type_deallocate = FALSE; 
head += sizeof (msg_type_t) ; 

bcopy ( stream->chars , head, stream->nbchars) ; 
head += stream->nbchars; 
free(stream->chars) ; 

type = head; 

type->msg_type_name = MSG_TYPE_INTEG ER_3 2 ; 

Lype->msg_type_size = sizeof (int) * 0; 
type->msg_type_number = stream->nbints; 

Lype->msg_type_inline = TRUE; 
type->msg_type_longform = FALSE; 
type- >insg_type_deal locate = FALSE; 
head += sizeof (msg_type_t) ; 
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bcopy (sLre/iiii *>j.nl:s , I toad, st:ieam->nlj i nt.« 4 si z&oL ( ini ) ) ; 
head i -- sti enm- >nb.inls * sizeof (int) ; 
free ( stream- >ints) / 

) else { 

msg_type_long_t *type; 

vm_address_t buffer; 

type = head; 

type->msg_type_header .msg_type_riame = 0; 
type->msg_type_header ,msg_type_size = 0? 
t.ype->msg_type_header .msg_type_number = 0; 
typt?->iMsy_type_header. msg_type_i.nl ino - FAbSE; 

I ype->M 3 g_type_header .msg_type_lony form = TRUE; 
fype-’>msg_Lype_header .msg_type_dea 1 locate - TRUE; 

Lype->iusy_type_long_name = MSG_TYPE_J3YTE; 
t.ype->msg_type_long_size = 0; 

type->insy_type„long_nuinber = stream->nbchars; 
head += sizeof (msg_type_long_t) ; 

if ( vm_al locate (task_nelf ( ) , ( vm_addres s_t 'l&buffer, streain->nbcliars , 1) !=KERN_ 

SUCCESS) 

BUG ( "NXCloseEncodePortStream: can't allocate (chars)'); 
bcopy (streain->chars, (char *)bu££er, stream->nbchars) ; 

((jut *) liead) [0] = buffer; 
head i= sizeof (int) ; 
f ree (stream->chars) ; 

type = liead; 

type->insg_type_header . msg_type_name = 0; 
type->msg_type_header .msg_type_size = 0; 
type->msg_type_header .msg_type_number = 0; 
type->msg_type_lieader ,msg_type_inline = FALSE; 

Lype->msg_type_header .msg_type_longforra = TRUE; 
t.ype->nisg_type_header ,msg_type_deallocate = TRUE; 
l:ype->msg_type_.l ong_name = MSG_TYPE_IMTEGEU_32; 
type->msg_type_loiig_size = sizeof (int I * 8; 
typo->msg_type_long_number = stream->nbints; 

head t= sizeof (msg_type_long_t) ; , . 

if (vm_al locate ( task_self ( I , ( vm_addr;ess_t *)&bu£fer, stream->nbiiits sizeof (rnt) 

, 1) != KERN_SUCCKSS) 

DUG ( 'NXCloseEacodePorLStream: can't allocate (ints)"); 
bcopy (streain->ints, (char *) buffer, stream->nbints * sizeof (int) I ; 

((int *)liead)(0) = buffer; 
head += sizeof (int) ; 
free (stream->ints) ; 


) 

stream->msg->msg_type = MSG_TYPE_NORMAL; 

stream- >msg->msg_size = head - (void *) stream->nisg; 

free (stream) ; 

) 

void NXCloseDecodePortStream(NXPortStream 'stream) ( 

if (stream->write) BUG ( -NXCloseDecodePortStream" ) ; 
iE (! stream- >msg->msg_simple) { 

vo iU 'head = ((void *) stream- >msg) +sizeof(reniote_iiiessage_t) ; 

msg_type_long_t 'type; 
type = head; 

if (type->msg_type_long_name != MSG_TYPE_BYTE) 

BUG ( "NXOpenDecodePortStream-char') ; 
liead i = sizeof (msg_type_long_t) ; 

if (vm_deoilocate(task_self () , ((int MheadHO), type->msy_type_long_number ) !=KE 
RN_SUCCESS) ■* 1 * 

BUG ( "NXCloseDecodePortStream: can't deallocate (chars)”): 
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head i= sizeof (int); 
type = head; 

if ( type->rasg_type_long_name != MSG_TYPE_INTEGER_32) 

BUG ( "NXOpenDecodePortStream-int " ) ; 
head i = sizeof (insg_t.ype_long._t) ; 

if (vm_deal locate ( task_sel£ ( ) , (lint *)head)[OJ, type->msg_type_long_number * size 
of (int) ) != KERN_SUCCESS) 

BUG! "NXCloseDecodePortStream: can't deallocate tints) ") ; 
liead sizeof (int); 


} 

free (stream) ; 


int NXGetPortStreainSequence (WXPortStream ‘stream) ( 

remote_message_t ‘liead = (remote_inessage_t * ) stream->msg ; 
return head->sequence; 

) 


/****»«« (Writing and reading arbitrary data *******/ 

void NXWri tePortTypelnternal (NX Port Stream ‘stream, const char ‘type, const void ‘data) ( 
switch (‘type) ( 

case 'c' : case ’C' : ( 

char cc = 0 ; / * for padding * I 

cc = * ( (char *)data) ; 

_NXEncodeInt (stream, cc) ; 
break ; 

) 

case ' s' : case 'S’ ; ( 

short ss = 0; /* for padding */ 

ss = ‘((short *)data); 

_NXEncodeInt (stream, ss) ; 
break; 

} 

case 'i'; case 'I': case '1': case 'L': 

_NXEncodelnt (stream, ‘(lint *)data)); 
break; 
case ' f ' : 

_NXEncodeFloat (stream, ‘((float ‘Jdata)); 
break; 
case 'd' : 

_NXEncodeDouble (stream, ‘((double ‘(data)); 
break ; 
case : 

PortlnternalWriteObject (stream, ‘((id *)data)); 
break ; 
case ' * ' : 

If if DEBUG_LEAKS 

syslog (L0G_ERR, •*** Remote Objects; un-freeable string encoding: %s",. ‘((char 

**)data) ) ; 
flendif 

_NXEncodeChars (stream, ‘((char “Jdata) ); 
break; 
case ' % ' : 

_HXEncodeChars (stream, * ( (NXAtom * Jdata) ); 
break; 
case ' : ' : ( 

SEL sel = ‘((SEE * Jdata) ; 

char *str = NULL; 

if (sel) str = sel_getNarae (sel) ; 

_NXEucodeCliars (stream, str); 
break; 
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case ' I ' : 
break; 

default: BUG ( 'NXWritePortTypelnternal : unknown type descriptor*); 

) 

) 

void NXReadPortTypelnternal (NXPortStream ‘stream, const char ‘type, void ‘data) ( 
switch (‘type) ( 

case 'c' : case 'C' : ( 

signed char *ptr = data; 

*ptr = _NXDecodeInt (stream) ; 
break ; 

) 

case 's' : case 'S' : { 

short *ptr = data; 

*ptr = _NXDecodeInt (stream) ; 
break ; 

) 

case 'i': case 'I': case '1': case 'L': ( 

int *ptr = data i 

*ptr = _NXDecodeInt ! stream) ; 
break; 

) 

case ' f ' : ( 

float *ptr = data; 

*ptr = _NXDecodeFloat (stream) ; 
break ; 

) 

case 'd' : ( 

double *ptr = data; 

*ptr = _NXUecodeDouble (stream) ; 
break; 


case : { 

id *ptr = data; 

*ptr = PortlnternalReadObject (stream) ; 
break; 

) 

case ' * ' : ( 

char “ptr = data; 

*ptr = _NXDecodeChars (stream) ; 
break; 


case ' % ' : { 

NXAtom *ptr = data; 

*ptr = _NXDecodeUniqueString (stream) ; 
break; 


case ' : ' : ( 

SEL *ptr = data,- 

NXAtom selName = _NXDecodeUniqueString (stream) ; 

*ptr = _sel_registerName ( (char ‘IselName); 
break ; 

) 

case ' ! ' : • 
break ; 

default: BUG ( "NXReadPortTypelnternal : unknown type descriptor"); 

) 

void NXWritePortTypes (NXPortStream ‘stream, const char ‘type, ...) ( 
va_list args; 
va_start (args, type); 
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/ * wn could avoid i,._.it line at the cost of more painL,..-i debug */ 

_NXRncotIeCliars (stream, type); 
while (‘type) { 

NXWritePortTypelnternal (stream, type, va_arg(args, void * ) ) ) 
type = ty pe + + ; /‘ we restrict to monochar type descriptions V 

) 

va_end (args) ; 

] 

void NXReadPortTypes (NXPortStream ‘stream, const char ‘type, ...) { 

NXAtom readType; 

vallist args; 

va_s tart (args, type); 

readType = _NXDecodeUniqueString (stream) ; 

/* Vie could avoid next line at the cost of more painful debug */ 
chec:kExpected( readType, type) ; 
wliiie (‘type) ( 

NXReadPortTypelnternal (stream, type, va_arg(args, void *)); 
type = type++; /* we restrict to monochar type descriptions */ 

) 

va_end (args); 

) 

static void FortlnternalWriteObject (NXPortStream ‘stream, id object) { 

BOOL flag = NO; 

if (! ( stream->communication respondsTo: 8selector ( beforeEncoding ; onto s f reeAf terEncod 

ing : ) 1 ) BUGPPortlnternalWriteObject" ) ; 

object = [stream->communication beforeEncoding: object onto: stream f reeAf terEncoding : 
&f lag) ; 

_NXEncodeUool (stream, (object) ? YES : NO); 
if (object) ( 

Class class = (Class) [object class); 

if (! class) BUG ( • PortlnternalWriteObject ; found null class"); 

_NXEncodeCliars (stream, class->name) ; 
loliject writePortStreain: stream); 

_NXEncodeBool (stream, YES); 
if (flag) (object free); 

) 

) 

static id PortInternalReadObject (NXPortStream ‘stream) { 

id object; 

if (! _NXOecodeBool (stream) ) return nil; 
else ( 

NXAtom className = _NXDecodeUniqueString (stream) ; 

Class class = (Class) objc_getClass ((char *) className); 
if { ! class) BUG (“PortInternalReadObject: class not loaded"), ■ 

/* explicit class initialization */ 

(void) ((id) class self]; 

object = clags_createlnstance (class, 0); 

[object readPortStream: stream] ; 

if |l [stream->communication respondsTo i Sselector (aftert>ecodlng:from: ) ] ) BUGCPo 

rtlnternalWriteObject-l" ) ; .. . . 

object = (stream->communication afterDecoding : object from: streamj , 
if (! _NXDecodeBool (stream) ) BUG("PortInternalReadObject-2") ; 

return object; 

} 

) 
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We claim: 

1. A method for sending an object oriented programming 

language based message having dynamic binding from a 
first object in a first process to a second object in a second 
process, said method comprising the steps of: 5 

transmitting, using a first processing means, said object 
oriented programming language based message to a 
first proxy in said first process; 
using said first proxy and said first processing means, 
encoding said object oriented programming language to 
based message into an operating system based message 
at ran time; 

transmitting said operating system based message to said 
second process in said second processing means at run 
time; i 5 

decoding, using a second process, said operating system 
based message into a language based message; 
transmitting, using said second processing means, said 
object oriented programming language based message 
to said second object in said second process; 20 

executing said object oriented programming language 
based message by said second object in said second 
process. 

2. The method of claim 1 further including the steps of: 
said second object in said second process and generating 25 

an object oriented programming language based result; 
encoding, using said second processing means, said object 
oriented programming language based result into an 
operating system based result at run time; 
transmitting, using said second processing means, said 
operating system based result to said first process at run 
time; 

decoding said operating system based result into an object 
oriented programming language based result at run 35 
time, using said first processing means; 
transmitting, using said first processing means, said object 
oriented programming language based result to said 
first object. 

3. The method of claim 1 wherein said object oriented 40 
programming language based message comprises a method 
and an argument. 

4. The method of claim 1 wherein said second object 

executes said method on said argument when executing said 
message. 45 

5. The method of claim 1 wherein the step of executing 
said object oriented programming language based message 
further includes the steps of: 

said second object determining, using said second pro- 
cessing means, whether additional information is 50 
needed to execute said object oriented programming 
language based message; 

said second object generating, using said second process- 
ing means, an object oriented programming language 
based query if it is determined that additional informa- 55 
tion is needed; 

encoding, using said second processing means, said object 
oriented programming language based query into an 
operating system based query at run time if it is g0 
determined that additional information is needed; 
transmitting said operating system based query to said 
first process at run time, using said second processing 
means if it is determined that additional information is 
needed; 65 

decoding, using said first processing means, said operat- 
ing system based query into an object oriented pro- 
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gramming language based query at run time if it is 
determined that additional information is needed; 
transmitting, using said first processing means, said object 
oriented programming language based query to said 
first object if it is determined that additional informa- 
tion is needed. 

6. The method of claim 5 further including the steps of: 
said first object generating, using said first processing 

means, an object oriented programming language based 
reply to said object oriented programming language 
based query; 

encoding said object oriented programming language 
based reply into an operating system based reply at run 
time, using said first processing means; 
transmitting, using said first processing means, said oper- 
ating system based reply to said second process at run 
time; 

decoding, using said second processing means, said oper- 
ating system based reply into an object oriented pro- 
gramming language based reply at run time; 
transmitting, using said second processing means, said 
object oriented programming language based reply to 
said second object. 

7. The method of claim 6 wherein said first processing 
means and said second processing means are the same 
processing means. 

8. The method of claim 1 wherein said object oriented 
programming language based message comprises an objec- 
tive C message. 

9. The method of claim 1 wherein said operating system 
based message comprises a Mach message. 

10. The method of claim 1 wherein said first proxy 
represents said second object. 

11. A method for sending an object oriented programming 
language based message having dynamic binding from a 
first object in a first process to a second object in a second 
process, said method comprising the steps of: 

transmitting, using a first processing means, said object 
oriented programming language based message to a 
first proxy in said first process; 
using said first proxy and said first processing means, 
encoding said object oriented programming language 
based message into an operating system based message 
at run time; 

transmitting, using said first processing means, said oper- 
ating system based message to said second process at 
run time; 

decoding, using said second processing means, said oper- 
ating system based message into an object oriented 
programming language based message at ran time; 
transmitting, using said second processing means, said 
object oriented programming language based message 
to said second object; 

said second object generating an object oriented pro- 
gramming language based query, using said second 
processing means; 

creating, using said second processing means, a second 
proxy in said second process; 
transmitting, using said second processing means, said 
object oriented programming language based query to 
said second proxy; 

using said second proxy and said second processing 
means, encoding said object oriented programming 
language based query into an operating system based 
query at run time; 
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transmitting, using said second processing means, said 
operating system based query to said first process at run 
time; 

decoding, using said first processing means, said operat- 
ing system based query into an object oriented pro- 5 
gramming language based query at run time; 
transmitting, using said first processing means, said object 
oriented programming language based query to said 
first object; 

said first object generating an object oriented program- to 
ming language based reply, using said first process- 
ing means; 

encoding, using said first processing means, said object 
oriented programming language based reply into an 
operating system based reply at mn time; 15 

transmitting, using said first processing means, said oper- 
ating system based reply to said second process at run 
time; 

decoding, using a second processing means, said operat- 
ing system based reply into an object oriented program- 20 
ming language based reply at run time; 
transmitting, using said second processing means, said 
object oriented programming language based reply, 
using said second processing means, and generating an 
object oriented programming language based result; 25 
encoding, using said second processing means, said object 
oriented programming language based result into an 
operating system based result at mn time; 
transmitting, using said second processing means, said 
operating system based result to said first process at mn 30 
time; 

decoding, using said first processing means, said operat- 
ing system based result into an object oriented pro- 
gramming language based result; 
transmitting, using stud first processing means, said object 
oriented programming language based result to said 
first object. 

12. The method of claim 11 wherein said object oriented 
programming language based message comprises a method 
and an argument. 

13. The method of claim 12 wherein said second object 
executes said method on said argument when executing said 
message. 

14. The method of claim 11 wherein said first process and 
said second process are located on first and second comput- 
ers respectively. 

15. The method of claim 11 wherein said object oriented 
programming language based message comprises an objec- 
tive C message. 

16. The method of claim 11 wherein said operating system 
based message comprises a Mach message. 

17. The method of claim 11 wherein said first proxy 
represents said second object. 

18. The method of claim 11 wherein said second proxy 
represents said first object. 

19. A method for sending, in a C environment with 
minimal run time support, an object oriented programming 
language based message having dynamic binding from a 
first object in a first process to a second object in a second 
process, said method comprising the steps of: 

transmitting, using a first processing means implementing 
said C environment, said object oriented programming 
language based message to a first proxy in said first 
process; 

using said first proxy and said first processing means, 
encoding said object oriented programming language 
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based message into an operating system based message 
at run time; 

transmitting said operating system based message to said 
second process at run time; 

decoding, using a second processing means implementing 
said C environment, said operating system based mes- 
sage into a language based message; 
transmitting, using said second processing means, said 
object oriented programming language based message 
to said second object. 

20. The method of claim 19 further including the steps of: 
said second object executing said object oriented pro- 
gramming language based message, using said second 
processing means, and generating an object oriented 
programming language based result; 

encoding, using said second processing means, said object 
oriented programming language based result into an 
operating system based result at run time; 
transmitting, using said second processing means, said 
operating system based result to said first process at mn 
time; 

decoding said operating system based result into an object 
oriented programming language based result at mn 
time, using said first processing means; 
transmitting, using said first processing means, said object 
oriented programming language based result to said 
first object. 

21. The method of claim 20 wherein the step of executing 
said object oriented programming language based message 
further includes the steps of: 

said second object determining, using said second pro- 
cessing means, whether additional information is 
needed to execute said object oriented programming 
language based message; 

said second object generating, using said second process- 
ing means, an object oriented programming language 
based query if it is determined that additional informa- 
tion is needed; 

encoding, using said second processing means, said object 
oriented programming language based query into an 
operating system based query at run time if it is 
determined that additional information is needed; 
transmitting said operating system based query to said 
first process at run time, using said second processing 
means if it is determined that additional information is 
needed; 

decoding, using said first processing means, said operat- 
ing system based query into an object oriented pro- 
gramming language based query at run time if it is 
determined that additional information is needed; 
transmitting, using said first processing means, said object 
oriented programming language based query to said 
first object if it is determined that additional informa- 
tion is needed. 

22. The method of claim 21 further including the steps of: 
said first object generating, using said first processing 

means, an object oriented programming language based 
reply to said object oriented programming language 
based query; 

encoding said object oriented programming language 
based reply into an operating system based reply at run 
time, using said first processing means; 
transmitting, using said first processing means, said oper- 
ating system based reply to said second process at run 
time; 
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decoding, using said second processing means, said oper- 
ating system based reply into an object oriented pro- 
gramming language based reply at mn time; 

transmitting, using said processing means, said object 
oriented programming language based reply to said 5 
second object. 

23. The method of claim 21 wherein said operating 
system based message comprises a Mach message. 
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24. The method of claim 21 wherein said first processing 
means and said second processing means are the same 
processing means. 
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